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 to improve the security layer but I've no any experience at this.
When I had looked at postman for possible auth methods and researched google I've seen the given options:
- API key
- Bearer Token
- Basic Auth
- Digest Auth
- OAuth 1.0
- OAuth 2.0
- Hawk Auth
- AWS Signature
- NTLM Auth
Digest, Hawk, AWS and NTLM seem like to be really specific cases so I omit them.
I've heard just in general about API key, Bearer Token and OAuth 1.0\2.0, but OAuth 1.0 seems to be outdated or something (I mean, there is a reason for version 2.0 to exist).
So as a result seems like I have 3 possible variants:
- API Key
- Bearer Token
- OAuth 2.0
Is my assumption correct? What is the most widely-used case in modern web apps for security layer?
I don't ask a full description for each case, just general recommendations, maybe some links\resources to look at.
What should I concentrate on?
What mistakes in my description\explanation do you see?
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.
Some of the most common ways of authentication in REST API's are explained below
1.Basic Auth
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
2. JWT / Bearer token
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.
3. API key
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
4. Oauth2.0
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)
Advantage of oauth2.0
- access_token received will have authentication and authorization both. So it will be helpful to provide specific scope to access_token.
(Say stack overflow accesses basic profile info, candy crush accesses more information including scope of posting on behalf of you)
- life span of access_token, grant_type of refresh_token.
Access tokens have limited lifetimes. If client application needs access to Resource beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows client application to obtain new access tokens.
grant types: (authorization code, implicit, password, client credntial, refresh token)
Note:
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.
5. Digest auth
I have not worked on digest auth. Refer this thread for more details
Transport layer security essentials
SSL
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
