I\'m writing a wep app (rest api actually) using Spring, Spring Security. Right now I have basic and really straightforward auth using username, password and roles. I want t
As far as web application is concerned web application request should have state, session is the most common way to have state.
And when we consider REST API's requests are preferred to be stateless, but to authenticate and identify user or client there are lot of ways as OP mentioned.
In Basic authentication user sends his credential encoded by base64 encoder.
Credentials are sent in Authorization header with Basic prefix as given below.
"Basic "+ encodeUsingBase64(username+":"+password)
If Your REST API is secured by Basic auth, a user who is not part of application(a user who is not present in database of server) can't access secured resources.
Ideally Basic auth is for only application users
JSON Web Token (JWT) is an open standard (RFC 7519) where a server shares a digitally signed token with the client, it can be used by both application users and non application users with server side logic which extracts user information from the payload of token and validates with it's database entries for authorization. Here with JWT use case is not limited in some implementation payload can contain authorization information as well. Single Sign On is a feature that widely uses JWT nowadays.
Compared to basic authentication
Basic authentication is a authentication step where complete credential(including password) will be sent in each request.
JWT is a post authentication step, where a authenticated user receives a signed token which doesn't contains password information.
It has no standards, it might be randomly generated string issued to the users of API. Use case will be different for different issuer. It is well discussed here
Oauth2 is a different category. In one sentense it is not about securing all application API's but providing access to user resource
to the third party applications
with the consent of user
.
it has mainly 4 parts. Lets take example of Facebook
1. Authorization Server [Facebook]
2. Resource server [Facebook and resource will be your profile]
3. Client [Stack overflow, Quora, Candy crush, Subway Surfer etc]
4. Resource owner [You (If Authenticated)]
Resource server may consists of both secured and unsecured API's. For accessing secured API's Client need access_token which is issued by Authorization server. access_token issued is a random string and is also stored in authorization server database along with the associated user, scope(read
, read_profile_info
, write
).
Here Resource owner(You) giving consent to the Authorization server to grant a access_token of scope(read
,read-profile
,post-to-my-timeline
etc) to the Client(Quora
,StackOverflow
,Candy-Crush
etc)
Oauth2 Auth server not only for applications like facebook and Google but also Your application can have oauth2 server set up, and you can provide your clients access_token (to integrate your API with their application) with different scope, lifespan based on subscription/license.
I have not worked on digest auth. Refer this thread for more details
Any of the above authentication is concerned transport layer security(SSL) is important to ensure credentials/token you pass in subsequent requests is not captured as plain text.
X.509 (has advantage over SSL)SSL certificate is sent by server to client.(Any client which makes request to server receives SSL copy. There is no restriction, any client can receive SSL certificate).
But in case of X.509 client certificate is created using server SSL certificate and it is secretly shared with the client. Client uses X.509 certificate to communicate with server. Here one important point to be noted that for different clients different client certificate will be generated to identify each client. What X.509 ensures is
Security(Who don't have client certificate can't access API's)
Identity(server can identify client based on certificate subject)