I'm writing a RESTful service (Java EE, Jersey) and a client application that communicates with it, and I wish to secure it and store any usernames & passwords dedicated in my own database.
I do not want the client to store the username and password locally, not in any form such as base-64 or other encoding at all, I rather have something like the OAuth2 authorization system, where the client app only stores a refresh & access tokens after the resource owner signed-in, but I do not need to provide access to 3rd party services.
Securing my service using Basic auth means the client app has to store the password and send it for each future request, so that's not what I need.
I'm aware that OAuth is intended for different situations, where there are more than just 2 parties involved (see other question).
as mentioned here https://blog.apigee.com/detail/when_to_use_oauth:
OAuth is the only realistic choice for a web application that itself uses another web application's API on behalf of the user. For instance, consider a web application that integrates with Twitter. (Perhaps it's a geolocation app like Foursquare that offers the ability to tweet where you are and what you're doing.)
So what is the correct standardized method to secure my RESTful service if I do not wish to re-invent the wheel and create my own auth method, and if "Basic" is not what I need because it forces me to store the credentials locally on the client, and OAuth is probably an overkill with it's 3rd party access nature.
P.S- I do wish to provide users with an option to sign-in to my service using facebook or open-id, but that's another story I guess.