© Prabath Siriwardena 2020
P. SiriwardenaAdvanced API Securityhttps://doi.org/10.1007/978-1-4842-2050-4_4

4. OAuth 2.0 Fundamentals

Prabath Siriwardena1 
(1)
San Jose, CA, USA
 

OAuth 2.0 is a major breakthrough in identity delegation. It has its roots in OAuth 1.0 (see Appendix B), but OAuth Web Resource Authorization Profiles (see Appendix B) primarily influenced it. The main difference between OAuth 1.0 and 2.0 is that OAuth 1.0 is a standard protocol for identity delegation, whereas OAuth 2.0 is a highly extensible authorization framework. OAuth 2.0 is already the de facto standard for securing APIs and is widely used by Facebook, Google, LinkedIn, Microsoft (MSN, Live), PayPal, Instagram, Foursquare, GitHub, Yammer, Meetup, and many more. There is one popular exception: Twitter still uses OAuth 1.0.

Understanding OAuth 2.0

OAuth 2.0 primarily solves the access delegation problem. Let’s say you want a third-party application to read your status messages on your Facebook wall. In other words, you want to delegate the third-party application the access to your Facebook wall. One way to do that is by sharing your Facebook credentials with the third-party application, so it can directly access your Facebook wall. This is called access delegation by credential sharing. Even though this solves the access delegation problem, once you share your Facebook credentials with the third-party application, it can use your credentials to do anything it wants, which in turns creates more problems! OAuth 2.0 solves this problem in a way you do not need to share your credentials with third-party applications, but only share a time-bound temporary token that is only good enough for a well-defined purpose. Figure 4-1 shows at a high level how access delegation works with OAuth 2.0, and the following explains each step in Figure 4-1:
  1. 1.

    The user visits the third-party web application and wants to let the web application publish messages to his/her Facebook wall. To do that, the web application needs a token from Facebook, and to get the token, it redirects the user to Facebook.

     
  2. 2.

    Facebook prompts the user to authenticate (if not authenticated already) and requests the consent from the user to give permissions to the third-party web application to publish messages to his/her Facebook wall.

     
  3. 3.

    User authenticates and provides his/her consent to Facebook, so that Facebook can share a token with the third-party web application. This token is only good enough to publish messages to the Facebook wall for a limited period and cannot do anything else. For example, the third-party web application cannot send friend requests, delete status messages, upload photos, and so on with the token.

     
  4. 4.

    The third-party web application gets a token from Facebook. To explain what exactly happens in this step, first we need to understand how OAuth 2.0 grant types work, and we discuss that later in the chapter.

     
  5. 5.

    The third-party web application accesses the Facebook API with the token provided to it by Facebook in step 4. Facebook API makes sure only requests that come along with a valid token can access it. Then again later in the chapter, we will explain in detail what happens in this step.

     
../images/323855_2_En_4_Chapter/323855_2_En_4_Fig1_HTML.jpg
Figure 4-1

OAuth 2.0 solves the access delegation problem by issuing a temporary time-bound token to a third-party web application that is only good enough for a well-defined purpose

OAuth 2.0 Actors

OAuth 2.0 introduces four actors in a typical OAuth flow. The following explains the role of each of them with respect to Figure 4-1:
  1. 1.

    Resource owner: One who owns the resources. In our example earlier, the third-party web application wants to access the Facebook wall of a Facebook user via the Facebook API and publish messages on behalf of him/her. In that case, the Facebook user who owns the Facebook wall is the resource owner.

     
  2. 2.

    Resource server: This is the place which hosts protected resources. In the preceding scenario, the server that hosts the Facebook API is the resource server, where Facebook API is the resource.

     
  3. 3.

    Client: This is the application which wants to access a resource on behalf of the resource owner. In the preceding use case, the third-party web application is the client.

     
  4. 4.

    Authorization server: This is the entity which acts as a security token service to issue OAuth 2.0 access tokens to client applications. In the preceding use case, Facebook itself acts as the authorization server.

     

Grant Types

A grant type in OAuth 2.0 defines how a client can obtain an authorization grant from a resource owner to access a resource on his/her behalf. The origin of the word grant comes from the French word granter which carries the meaning consent to support. In other words, a grant type defines a well-defined process to get the consent from the resource owner to access a resource on his/her behalf for a well-defined purpose. In OAuth 2.0, this well-defined purpose is also called scope. Also you can interpret scope as a permission, or in other words, scope defines what actions the client application can do on a given resource. In Figure 4-1, the token issued from the Facebook authorization server is bound to a scope, where the client application can only use the token to post messages to the corresponding user’s Facebook wall.

The grant types in OAuth 2.0 are very similar to the OAuth profiles in WRAP (see Appendix B). The OAuth 2.0 core specification introduces four core grant types: the authorization code grant type, the implicit grant type, the resource owner password credentials grant type, and the client credentials grant type. Table 4-1 shows how OAuth 2.0 grant types match with WRAP profiles.
Table 4-1

OAuth 2.0 Grant Types vs. OAuth WRAP Profiles

OAuth 2.0

OAuth WRAP

Authorization code grant type

Web App Profile/Rich App Profile

Implicit grant type

–

Resource owner password credentials grant type

Username and Password Profile

Client credentials grant type

Client Account and Password Profile

Authorization Code Grant Type

The authorization code grant type in OAuth 2.0 is very similar to the Web App Profile in WRAP. It’s mostly recommended for applications—either web applications or native mobile applications—that have the capability to spin up a web browser (see Figure 4-2). The resource owner who visits the client application initiates the authorization code grant type. The client application, which must be a registered application at the authorization server, as shown in step 1 in Figure 4-2, redirects the resource owner to the authorization server to get the approval. The following shows an HTTP request the client application generates while redirecting the user to the authorize endpoint of the authorization server:
https://authz.example.com/oauth2/authorize?
                   response_type=code&
                   client_id=0rhQErXIX49svVYoXJGt0DWBuFca&
                   redirect_uri=https%3A%2F%2Fmycallback
The authorize endpoint is a well-known, published endpoint of an OAuth 2.0 authorization server. The value of response_type parameter must be code. This indicates to the authorization server that the request is for an authorization code (under the authorization code grant type). client_id is an identifier for the client application. Once the client application is registered with the authorization server, the client gets a client_id and a client_secret. During the client registration phase, the client application must provide a URL under its control as the redirect_uri, and in the initial request, the value of the redirect_uri parameter should match with the one registered with the authorization server. We also call the redirect_uri the callback URL. The URL-encoded value of the callback URL is added to the request as the redirect_uri parameter. In addition to these parameters, a client application can also include the scope parameter. The value of the scope parameter is shown to the resource owner on the approval screen: it indicates to the authorization server the level of access the client needs on the target resource/API.
../images/323855_2_En_4_Chapter/323855_2_En_4_Fig2_HTML.jpg
Figure 4-2

Authorization code grant type

In step 5 in Figure 4-2, the authorization server returns the requested code to the registered callback URL (also known as redirect_uri) of the client application. This code is called the authorization code. Each authorization code should have a lifetime. A lifetime longer than 1 minute isn’t recommended:

https://callback.example.com/?code=9142d4cad58c66d0a5edfad8952192

The value of the authorization code is delivered to the client application via an HTTP redirect and is visible to the resource owner. In the next step (step 6), the client must exchange the authorization code for an OAuth access token by talking to the OAuth token endpoint exposed by the authorization server.

Note

The ultimate goal of any OAuth 2.0 grant type is to provide a token (which is known as access token) to the client application. The client application can use this token to access a resource. An access token is bound to the resource owner, client application, and one or more scopes. Given an access token, the authorization server knows who the corresponding resource owner and client application and also what the attached scopes are.

The token endpoint in most of the cases is a secured endpoint. The client application can generate the token request along with the corresponding client_id (0rhQErXIX49svVYoXJGt0DWBuFca) and the client_secret (eYOFkL756W8usQaVNgCNkz9C2D0a), which will go in the HTTP Authorization header. In most of the cases, the token endpoint is secured with HTTP Basic authentication, but it is not a must. For stronger security, one may use mutual TLS as well, and if you are using the authorization code grant type from a single-page app or a mobile app, then you may not use any credentials at all. The following shows a sample request (step 6) to the token endpoint. The value of the grant_type parameter there must be the authorization_code, and the value of the code should be the one returned from the previous step (step 5). If the client application sent a value in the redirect_uri parameter in the previous request (step 1), then it must include the same value in the token request as well. In case the client application does not authenticate to the token endpoint, you need to send the corresponding client_id as a parameter in the HTTP body:

Note

The authorization code returned from the authorization server acts as an intermediate code. This code is used to map the end user or resource owner to the OAuth client. The OAuth client may authenticate itself to the token endpoint of the authorization server. The authorization server should check whether the code is issued to the authenticated OAuth client prior to exchanging it for an access token.

> curl -v –k -X POST --basic
     -u 0rhQErXIX49svVYoXJGt0DWBuFca:eYOFkL756W8usQaVNgCNkz9C2D0a
     -H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8"
     -d "grant_type=authorization_code&
         code=9142d4cad58c66d0a5edfad8952192&
         redirect_uri=https://mycallback"
         https://authz.example.com/oauth2/token

Note

The authorization code should be used only once by the client. If the authorization server detects that it’s been used more than once, it must revoke all the tokens issued for that particular authorization code.

The preceding cURL command returns the following response from the authorization server (step 7). The token_type parameter in the response indicates the type of the token. (The section “OAuth 2.0 Token Types” talks more about token types.) In addition to the access token, the authorization server also returns a refresh token, which is optional. The refresh token can be used by the client application to obtain a new access token before the refresh token expires. The expires_in parameter indicates the lifetime of the access token in seconds.
{
      "token_type":"bearer",
      "expires_in":3600,
      "refresh_token":"22b157546b26c2d6c0165c4ef6b3f736",
      "access_token":"cac93e1d29e45bf6d84073dbfb460"
}

Note

Each refresh token has its own lifetime. Compared to the lifetime of the access token, the refresh token’s is longer: the lifetime of an access token is in minutes, whereas the lifetime of a refresh token is in days.

Implicit Grant Type

The implicit grant type to acquire an access token is mostly used by JavaScript clients running in the web browser (see Figure 4-3). Even for JavaScript clients now, we do not recommend using implicit grant type, rather use authorization code grant type with no client authentication. This is mostly due to the inherent security issues in the implicit grant type, which we discuss in Chapter 14. The following discussion on implicit grant type will help you understand how it works, but never use it in a production deployment.
../images/323855_2_En_4_Chapter/323855_2_En_4_Fig3_HTML.jpg
Figure 4-3

Implicit grant type

Unlike the authorization code grant type, the implicit grant type doesn’t have any equivalent profiles in OAuth WRAP. The JavaScript client initiates the implicit grant flow by redirecting the user to the authorization server. The response_type parameter in the request indicates to the authorization server that the client expects a token, not a code. The implicit grant type doesn’t require the authorization server to authenticate the JavaScript client; it only has to send the client_id in the request. This is for logging and auditing purposes and also to find out the corresponding redirect_uri. The redirect_uri in the request is optional; if it’s present, it must match what is provided at the client registration:
https://authz.example.com/oauth2/authorize?
                  response_type=token&
                  client_id=0rhQErXIX49svVYoXJGt0DWBuFca&
                  redirect_uri=https%3A%2F%2Fmycallback
This returns the following response. The implicit grant type sends the access token as a URI fragment and doesn’t provide any refreshing mechanism:
https://callback.example.com/#access_token=cac93e1d29e45bf6d84073dbfb460&expires_in=3600

Unlike the authorization code grant type, the implicit grant type client receives the access token in the response to the grant request. When we have something in the URI fragment of a URL, the browser never sends it to the back end. It only stays on the browser. So when authorization server sends a redirect to the callback URL of the client application, the request first comes to the browser, and the browser does an HTTP GET to the web server that hosts the client application. But in that HTTP GET, you will not find the URI fragment, and the web server will never see it. To process the access token that comes in the URI fragment, as a response to HTTP GET from the browser, the web server of the client application will return back an HTML page with a JavaScript, which knows how to extract the access_token from the URI fragment, which still remains in the browser address bar. In general this is how single-page applications work.

Note

The authorization server must treat the authorization code, access token, refresh token, and client secret key as sensitive data. They should never be sent over HTTP—the authorization server must use Transport Layer Security (TLS). These tokens should be stored securely, possibly by encrypting or hashing them.

Resource Owner Password Credentials Grant Type

Under the resource owner password credentials grant type, the resource owner must trust the client application. This is equivalent to the Username and Password Profile in OAuth WRAP. The resource owner has to give his/her credentials directly to the client application (see Figure 4-4).
../images/323855_2_En_4_Chapter/323855_2_En_4_Fig4_HTML.jpg
Figure 4-4

Resource owner password credentials grant type

The following cURL command talks to the token endpoint of the authorization server, passing the resource owner’s username and password as parameters. In addition, the client application proves its identity. In most of the cases, the token endpoint is secured with HTTP Basic authentication (but not a must), and the client application passes its client_id (0rhQErXIX49svVYoXJGt0DWBuFca) and client_secret (eYOFkL756W8usQaVNgCNkz9C2D0a) in the HTTP Authorization header. The value of the grant_type parameter must be set to password:
> curl -v -k -X POST --basic
     -u 0rhQErXIX49svVYoXJGt0DWBuFca:eYOFkL756W8usQaVNgCNkz9C2D0a
     -H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8"
     -d "grant_type=password&
         username=admin&password=admin"
         https://authz.example.com/oauth2/token
This returns the following response, which includes an access token along with a refresh token:
{
      "token_type":"bearer",
      "expires_in":685,"
      "refresh_token":"22b157546b26c2d6c0165c4ef6b3f736",
      "access_token":"cac93e1d29e45bf6d84073dbfb460"
}

Note

If using the authorization code grant type is an option, it should be used over the resource owner password credentials grant type. The resource owner password credentials grant type was introduced to aid migration from HTTP Basic authentication and Digest authentication to OAuth 2.0.

Client Credentials Grant Type

The client credentials grant type is equivalent to the Client Account and Password Profile in OAuth WRAP and to two-legged OAuth in OAuth 1.0 (see Appendix B). With this grant type, the client itself becomes the resource owner (see Figure 4-5). The following cURL command talks to the token endpoint of the authorization server, passing the client application’s client_id (0rhQErXIX49svVYoXJGt0DWBuFca) and client_secret (eYOFkL756W8usQaVNgCNkz9C2D0a).
../images/323855_2_En_4_Chapter/323855_2_En_4_Fig5_HTML.jpg
Figure 4-5

Client credentials grant type

> curl –v –k -X POST --basic
     -u 0rhQErXIX49svVYoXJGt0DWBuFca:eYOFkL756W8usQaVNgCNkz9C2D0a
     -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
     -d "grant_type=client_credentials"
     https://authz.example.com/oauth2/token
This returns the following response, which includes an access token. Unlike the resource owner password credentials grant type, the client credentials grant type doesn’t return a refresh token:
{     "token_type":"bearer",
      "expires_in":3600,
      "access_token":"4c9a9ae7463ff9bb93ae7f169bd6a"
}

This client credential grant type is mostly used for system-to-system interactions with no end user. For example, a web application needs to access an OAuth secured API to get some metadata.

Refresh Grant Type

Although it’s not the case with the implicit grant type and the client credentials grant type, with the other two grant types, the OAuth access token comes with a refresh token. This refresh token can be used to extend the validity of the access token without the involvement of the resource owner. The following cURL command shows how to get a new access token from the refresh token:
> curl -v -X POST --basic
    -u 0rhQErXIX49svVYoXJGt0DWBuFca:eYOFkL756W8usQaVNgCNkz9C2D0a
    -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
    -k -d "grant_type=refresh_token&
           refresh_token=22b157546b26c2d6c0165c4ef6b3f736"
    https://authz.example.com/oauth2/token
This returns the following response:
{
      "token_type":"bearer",
      "expires_in":3600,
      "refresh_token":"9ecc381836fa5e3baf5a9e86081",
      "access_token":"b574d1ba554c26148f5fca3cceb05e2"
}

Note

The refresh token has a much longer lifetime than the access token. If the lifetime of the refresh token expires, then the client must initiate the OAuth token flow from the start and get a new access token and refresh token. The authorization server also has the option to return a new refresh token each time the client refreshes the access token. In such cases, the client has to discard the previously obtained refresh token and begin using the new one.

How to Pick the Right Grant Type?

As we discussed at the very beginning of the chapter, OAuth 2.0 is an authorization framework. The nature of a framework is to provide multiple options, and it’s up to the application developers to pick the best out of those options, based on their use cases. OAuth can be used with any kind of application. It can be a web application, single-page application, desktop application, or a native mobile application.

To pick the right grant type for those applications, first we need to think how the client application is going to invoke the OAuth secured API: whether it is going to access the API by itself or on behalf of an end user. If the application wants to access the API just being itself, then we should use client credentials grant type and, if not, should use authorization code grant type. Both the implicit and password grant types are now obsolete.

OAuth 2.0 Token Types

Neither OAuth 1.0 nor WRAP could support custom token types. OAuth 1.0 always used signature-based tokens, and OAuth WRAP always used bearer tokens over TLS. OAuth 2.0 isn’t coupled into any token type. In OAuth 2.0, you can introduce your own token type if needed. Regardless of the token_type returned in the OAuth token response from the authorization server, the client must understand it before using it. Based on the token_type, the authorization server can add additional attributes/parameters to the response.

OAuth 2.0 has two main token profiles: OAuth 2.0 Bearer Token Profile and OAuth 2.0 MAC Token Profile. The most popular OAuth token profile is Bearer; almost all OAuth 2.0 deployments today are based on the OAuth 2.0 Bearer Token Profile. The next section talks about the Bearer Token Profile in detail, and Appendix G discusses the MAC Token Profile.

OAuth 2.0 Bearer Token Profile

The OAuth 2.0 Bearer Token Profile was influenced by OAuth WRAP, which only supported bearer tokens. As its name implies, anyone who bears the token can use it—don’t lose it! Bearer tokens must always be used over Transport Layer Security (TLS) to avoid losing them in transit. Once the bearer access token is obtained from the authorization server, the client can use it in three ways to talk to the resource server. These three ways are defined in the RFC 6750. The most popular way is to include the access token in the HTTP Authorization header:

Note

An OAuth 2.0 bearer token can be a reference token or self-contained token. A reference token is an arbitrary string. An attacker can carry out a brute-force attack to guess the token. The authorization server must pick the right length and use other possible measures to prevent brute forcing. A self-contained access token is a JSON Web Token (JWT), which we discuss in Chapter 7. When the resource server gets an access token, which is a reference token, then to validate the token, it has to talk to the authorization server (or the token issuer). When the access token is a JWT, the resource server can validate the token by itself, by verifying the signature of the JWT.

GET /resource HTTP/1.1
Host: rs.example.com
Authorization: Bearer JGjhgyuyibGGjgjkjdlsjkjdsd
The access token can also be included as a query parameter. This approach is mostly used by the client applications developed in JavaScript:
GET /resource?access_token=JGjhgyuyibGGjgjkjdlsjkjdsd
Host: rs.example.com

Note

When the value of the OAuth access token is sent as a query parameter, the name of the parameter must be access_token. Both Facebook and Google use the correct parameter name, but LinkedIn uses oauth2_access_token and Salesforce uses oauth_token.

It’s also possible to send the access token as a form-encoded body parameter. An authorization server supporting the Bearer Token Profile should be able to handle any of these patterns:
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
access_token=JGjhgyuyibGGjgjkjdlsjkjdsd

Note

The value of the OAuth bearer token is only meaningful to the authorization server. The client application should not try to interpret what it says. To make the processing logic efficient, the authorization server may include some meaningful but nonconfidential data in the access token. For example, if the authorization server supports multiple domains with multitenancy, it may include the tenant domain in the access token and then base64-encode (see Appendix E) it or simply use a JSON Web Token (JWT).

OAuth 2.0 Client Types

OAuth 2.0 identifies two types of clients: confidential clients and public clients. Confidential clients are capable of protecting their own credentials (the client key and the client secret), whereas public clients can’t. The OAuth 2.0 specification is built around three types of client profiles: web applications, user agent–based applications, and native applications. Web applications are considered to be confidential clients, running on a web server: end users or resource owners access such applications via a web browser. User agent–based applications are considered to be public clients: they download the code from a web server and run it on the user agent, such as JavaScript running in the browser. These clients are incapable of protecting their credentials—the end user can see anything in the JavaScript. Native applications are also considered as public clients: these clients are under the control of the end user, and any confidential data stored in those applications can be extracted out. Android and iOS native applications are a couple of examples.

Note

All four grant types defined in the OAuth 2.0 core specification require the client to preregister with the authorization server, and in return it gets a client identifier. Under the implicit grant type, the client doesn’t get a client secret. At the same time, even under other grant types, it’s an option whether to use the client secret or not.

Table 4-2 lists the key differences between OAuth 1.0 and OAuth 2.0 Bearer Token Profile.
Table 4-2

OAuth 1.0 vs. OAuth 2.0

OAuth 1.0

OAuth 2.0 Bearer Token Profile

An access delegation protocol

An authorization framework for access delegation

Signature based: HMAC-SHA256/RSA-SHA256

Nonsignature-based, Bearer Token Profile

Less extensibility

Highly extensible via grant types and token types

Less developer-friendly

TLS required only during the initial handshake

Secret key never passed on the wire

More developer-friendly

Bearer Token Profile mandates using TLS during the entire flow

Secret key goes on the wire (Bearer Token Profile)

Note

OAuth 2.0 introduces a clear separation between the client, the resource owner, the authorization server, and the resource server. But the core OAuth 2.0 specification doesn’t talk about how the resource server validates an access token. Most OAuth implementations started doing this by talking to a proprietary API exposed by the authorization server. The OAuth 2.0 Token Introspection profile standardized this to some extent, and in Chapter 9, we talk more about it.

JWT Secured Authorization Request (JAR)

In an OAuth 2.0 request to the authorize endpoint of the authorization server, all the request parameters flow via the browser as query parameters. The following is an example of an OAuth 2.0 authorization code grant request:
https://authz.example.com/oauth2/authorize?
                   response_type=token&
                   client_id=0rhQErXIX49svVYoXJGt0DWBuFca&
                   redirect_uri=https%3A%2F%2Fmycallback

There are a couple of issues with this approach. Since these parameters flow via the browser, the end user or anyone on the browser can change the input parameters that could result in some unexpected outcomes at the authorization server. At the same time, since the request is not integrity protected, the authorization server has no means to validate who initiated the request. With JSON Web Token (JWT) secured authorization requests, we can overcome these two issues. If you are new to JWT, please check Chapters 7 and 8. JSON Web Token (JWT) defines a container to transport data between interested parties in a cryptographically safe manner. The JSON Web Signature (JWS) specification developed under the IETF JOSE working group, represents a message or a payload, which is digitally signed or MACed (when a hashing algorithm is used with HMAC), while the JSON Web Encryption (JWE) specification standardizes a way to represent an encrypted payload.

One of the draft proposals1 to the IETF OAuth working group suggests to introduce the ability to send request parameters in a JWT, which allows the request to be signed with JWS and encrypted with JWE so that the integrity, source authentication, and confidentiality properties of the authorization request are preserved. At the time of writing, this proposal is in its very early stage—and if you are familiar with Security Assertion Markup Language (SAML) Single Sign-On, this is quite analogous to the signed authentication requests in SAML. The following shows the decoded payload of a sample authorization request, which ideally goes within a JWT:
{
  "iss": "s6BhdRkqt3",
  "aud": "https://server.example.com",
  "response_type": "code id_token",
  "client_id": "s6BhdRkqt3",
  "redirect_uri": "https://client.example.org/cb",
  "scope": "openid",
  "state": "af0ifjsldkj",
  "nonce": "n-0S6_WzA2Mj",
  "max_age": 86400
}
Once the client application constructs the JWT (a JWS or a JWE—please see Chapters 7 and 8 for the details), it can send the authorization request to the OAuth authorization server in two ways. One way is called passing by value, and the other is passing by reference. The following shows an example of passing by value, where the client application sends the JWT in a query parameter called request. The [jwt_assertion] in the following request represents either the actual JWS or JWE.
https://server.example.com/authorize?request=[jwt_assertion]
The draft proposal for JWT authorization request introduces the pass by reference method to overcome some of the limitations in the pass by value method, as listed here:

  • Many mobile phones in the market as of this writing still do not accept large payloads. The payload restriction is typically either 512 or 1024 ASCII characters.

  • The maximum URL length supported by older versions of the Internet Explorer is 2083 ASCII characters.

  • On a slow connection such as a 2G mobile connection, a large URL would cause a slow response. Therefore the use of such is not advisable from the user experience point of view.

The following shows an example of pass by reference, where the client application sends a link in the request, which can be used by the authorization server to fetch the JWT. This is a typical OAuth 2.0 authorization code request, along with the new request_uri query parameter. The value of the request_uri parameter carries a link pointing to the corresponding JWS or JWE.
https://server.example.com/authorize?
        response_type=code&
        client_id=s6BhdRkqt3&
        request_uri=https://tfp.example.org/request.jwt/Schjwew&
        state=af0ifjsldkj

Pushed Authorization Requests (PAR)

This is another draft proposal being discussed under the IETF OAuth working group at the moment, which complements the JWT Secured Authorization Request (JAR) approach we discussed in the previous section. One issue with JAR is each client has to expose an endpoint directly to the authorization server. This is the endpoint that hosts the corresponding JWT, which is used by the authorization server. With Pushed Authorization Requests (PAR) draft proposal, this requirement goes a way. PAR defines an endpoint at the authorization server end, where each client can directly push (without going through the browser) all the parameters in a typical OAuth 2.0 authorization request and then use the normal authorization flow via the browser to pass a reference to the pushed request. Following is an example, where the client application pushes authorization request parameters to an endpoint hosted at the authorization server. This push endpoint on the authorization server can be secured either with mutual Transport Layer Security (TLS) or with OAuth 2.0 itself (client credentials) or with any other means as agreed between the client application and the authorization server.
POST /as/par HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code&
state=af0ifjsldkj&
client_id=s6BhdRkqt3&
redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&
scope=ais
If the client follows the JAR specification which, we discussed in the previous section, it can also send a JWS or a JWE to the push endpoint in the following way.
POST /as/par HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
request=[jwt_assertion]
Once the push endpoint at the authorization server receives the preceding request, it has to carry out all the validation checks against the request that it usually performs against a typical authorization request. If it all looks good, the authorization server responds with the following. The value of the request_uri parameter in the response is bound to the client_id in the request and acts as a reference to the authorization request.
HTTP/1.1 201 Created
Date: Tue, 2 Oct 2019 15:22:31 GMT
Content-Type: application/json
{
  "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
  "expires_in": 3600
}
Upon receiving the push response from the authorization server, the client application can construct the following request with the request_uri parameter from the response to redirect the user to the authorization server.
https://server.example.com/authorize?
        request_uri=urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2

Summary

  • OAuth 2.0 is the de facto standard for securing APIs, and it primarily solves the access delegation problem.

  • A grant type in OAuth 2.0 defines how a client can obtain an authorization grant from a resource owner to access a resource on his/her behalf.

  • OAuth 2.0 core specification defines five grant types: authorization code, implicit, password, client credentials, and refresh.

  • Refresh grant type is a special grant type, which is used by an OAuth 2.0 client application to renew an expired or closer to expiry access token.

  • Implicit grant type and client credentials grant types do not return back any refresh tokens.

  • Implicit grant type is obsolete and is not recommended to use due to its own inherent security issues.

  • OAuth 2.0 supports two types of client applications: public clients and confidential clients. Single-page applications and native mobile applications fall under public clients, while web applications fall under confidential clients.

  • The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) draft proposal suggests to introduce the ability to send request parameters in a JWT.

  • The Pushed Authorization Requests (PAR) draft proposal suggests to introduce a push endpoint at the authorization server end, so the client applications can securely push all the authorization request parameters and then initiate the browser-based login flow.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
52.14.232.232