What is OAuth 2.0?

OAuth is a standard that apps can use to provide client applications with “secure delegated access”. OAuth works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials.

OAuth 2.0 protocol is explicitly designed to support a variety of different client types, which access REST APIs. This includes both applications running on web servers within the enterprise calling out to the cloud as well as applications running on employee or customer mobile devices. OAuth protocol supports this variety of client types by defining multiple mechanisms for getting a token where the different mechanisms acknowledge the client type constraints.

Tokens

Access tokens are the token the client uses to access the Resource Server (API). They’re meant to be short-lived. Think of them in hours and minutes, not days and month. You don’t need a confidential client to get an access token. You can get access tokens with public clients. They’re designed to optimize for internet scale problems. Because these tokens can be short lived and scale out, they can’t be revoked, you just have to wait for them to time out.

The other token is the refresh token. This is much longer-lived; days, months, years. This can be used to get new tokens. To get a refresh token, applications typically require confidential clients with authentication.

Refresh tokens can be revoked. When revoking an application’s access in a dashboard, you’re killing its refresh token. This gives you the ability to force the clients to rotate secrets. What you’re doing is you’re using your refresh token to get new access tokens and the access tokens are going over the wire to hit all the API resources. Each time you refresh your access token you get a new cryptographically signed token. Key rotation is built into the system.

How it works?

1. The User (aka. Resource Owner) provides his/her username and password to the Client.
2. The Client makes a Token Request to the Authorization Server, providing username and password.
3. The Authorization Server checks the credentials and if they are correct, it provides an access token and optionally a refresh token to the Client in the response.
4. In the requests to the REST server (to get data like people, articles…) the Client will provide the access token.
5. When the REST service process a request, it will validate the access token calling the token validation endpoint of the Authorization Server or by validating the token locally (e.g. if the access token is a JWT).
6. If the access token is correct, has not expired and has the right permissions (aka. “scopes”), the REST service will return the data that the Client was asking for.
7. When the Client detects that access_token has expired (e.g. because the REST server returns an error), it asks the Authorization Server for another access token using the refresh token using the so-called Refresh Token grant/flow.