What is the most common way to authenticate a modern web app?

Question

I'm writing a web app (REST API) using Spring, Spring Security. Right now I have Basic authentication and a really straightforward authorization using username, password and roles. I want to improve the security layer but I have no experience with this.

When I had looked at postman for possible authentication methods and searched on google I've seen there are these 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 to be really specific cases so I omit them.

I've heard just some general information 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 it seems that 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 for 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?

Answer 1

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}

1. 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)
2. 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

• Security(Who don't have client certificate can't access API's)

• Identity(server can identify client based on certificate subject)

Answer 2

Basic & Digest Authentication

Within each request, the login credentials will be sent with the request header. In Basic Authentication, username and password (login credentials) are not encrypted. Digest Authentication use encrypted password. Therefore digest Authentication more secure than

Basic Authentication

username and password are concatenated using “ : ” symbol (“username:password”) and after this string is encode using base64 and send with request header. This method is easy to implement, faster and supported by all browsers. The problem is base64 is not a encryption method therefore this method has poor security and someone can get easily login credentials.

Digest Authentication

Hashed password sent along with nonce value in header. Nonce value is server generated random value. This method more secure than basic authentication method. Also, Susceptible to attacks from the man in the middle. passwords are not as reliable on the server since bcrypt cannot be used.

Session-Based Authentication

Each request does not require the user to provide a username or password. After the credential validation, server create a session and store in the memory. Also, return the session Id to the browser and browser store the session Id as a cookie.

Token-Based Authentication

Instead of cookies, this method authenticates users using tokens. Tokens are not necessary to be saved in the server. JSON Web Token (JWT)is the most widely used token. JWT has three parts. header, payload and signature. There are different attack based on how the token is saved on client computer. Also, Tokens are not revocable. It can only be used before the expire.

OAuth & OpenID

This is a form of single sign on authentication. User can use existing details from a social networking instead of make an account for specifically for the website as well as this method use session-base authentication. Major advantage is the security than other methods but this is depend on another third-party application. Users who do not have accounts with the OpenID providers you’ve set up will be unable to use your application.