[Certification Authority] 2.OAUTH2 Authorization (cont.) & JWT (JSON Web Token)

1 RFC6749 What else can be perfected? 1.1 Revoking Tokens

In the previous [certification authority] 1.OAUTH2 license introduced OAUTH2 can help us solve the third party client access to protected resources, but only to provide how to obtain access_token, does not explain how to revoke a access_token. About this section OAuth2 separately defines a Rfc7009-oauth 2.0 token revocation To resolve the revocation token issue.

1.2 Token's Opacity on client

The "Access_token" provided by OAuth2 is a string that is opaque to the client, although there is "scope", "expires_in" and "Refresh_token "to aid, but also imperfect and scattered information. Also take a Ming Li example, " Xiao Ming authorized to print online and e-mail the website to visit their QQ space album." This sentence in double quotes has 4 important concepts:

1. The authorized Xiao Ming : Said to be Xiao Ming authorization, but not next door old king.
2. Authorized users to print online and email the website : to authorize the designated site, and not other such as 1024.com and other sites (you know ...) ）。
3. Xiao Ming 's own QQ space: to let the authorized person to access their information, not the information of the old king next door, Xiao Ming also did not have this authority, or the next door to the king of the night do not agree ...
4. Albums : Indicates that you can access my album, not my log, my other information.

So how do you get the additional information that is mentioned above? OAuth2 also provided a separate Rfc7662-oauth 2.0 token introspection to solve the problem of incomplete description of token.

This information is not only opaque to the client, but also opaque to the resource server, such as the authorization server and the resource server is deployed independently, and OAUTH2 requires the resource server to verify access token, how is this information not verified? Unless shared at the DB storage level of access token, this assumption is not supported by an Internet-scale environment as a protocol running on an Internet-scale network.

2 OAuth2 token Revocation (rfc7009-oauth2 token revocation)

In a nutshell, this protocol specifies what API a authorization server provides for the client to revoke Access_token or Refresh_token.

For example, the client initiates a request as follows:

Post/revoke http/1.1
Host:server.example.com
content-type:application/x-www-form-urlencoded
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW

Token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

The meanings are as follows:

1. /revoke: Is the API address that authorization server needs to provide, the client uses post to request this address.
2. content-type:application/x-www-form-urlencoded: Fixed this format.
3. Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW: Access the authorized credentials for the protected resource.
4. Token: Required, can be access_token or refresh_token content.
5. Token_type_hint: Optional, indicates the type of token, with a value of "Access_token" or "Refresh_token".

If the revocation succeeds, a response of HTTP status Code 200 will be returned.

3 OAuth2 Token metadata (Rfc7662-oauth2 token introspection)

In a nutshell, this specification expands an API interface (introspection Endpoint) for OAuth2, allowing the third-party client to query the information mentioned above (for example, whether Access_token is still valid, who issued it, who it is issued to, Metadata information about what scope and so on).

For example, the client initiates a request as follows:

Post/introspect http/1.1
Host:server.example.com
Accept:application/json
content-type:application/x-www-form-urlencoded
Authorization:bearer 23410913-abewfq.123483

Token=2yotnfzfejr1zcsicmwpaa&token_type_hint=access_token

It appears to be similar to the above request to revoke tokens, which have the following meanings:

1. /introspect: Is the API address that authorization server needs to provide, the client uses post to request this address.
2. Accept:application/json: Indicates that authorization server needs to return a JSON-formatted data.
3. content-type:application/x-www-form-urlencoded: Fixed this format.
4. Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW: Access the authorized credentials for the protected resource.
5. Token: Required, can be access_token or refresh_token content.
6. Token_type_hint: Optional, indicates the type of token, with a value of "Access_token" or "Refresh_token".

If the request succeeds, the following information is returned:

1 {2       "active": true, 3       "client_id": "L238j323ds-23ij4", 4       "Token_type": "Access_token", 5       "username": "JDoe", 6       "scope": "Read Write Dolphin", 7       "sub": "Z5o3uppc88qrajx00dis", 8       "AUD": "https:// Protected.example.net/resource ", 9       " ISS ":" https://server.example.com/","       exp ": 1419356238,11       " IAT " : 1419350238,12       "NBF": 1419350238,13       "JTI": "ABCDEFG" "       Extension_field": "Twenty-seven" 15}

The JSON properties have the following meanings (some of which are defined in the JSON Web token, and are described in detail in the reference link):

1. Active: Required. Indicates whether the token is still valid.
2. client_id: Optional. Represents the client to which token belongs. For example, the above online printing and mailing of the website .
3. Token_type: Optional. Represents the type of token. Corresponds to the token_type_hint of the pass.
4. USER_NAME: Optional. The name of the grantee who represents the token. Like xiaoming on the top.
5. Scope: Optional. Corresponds to the optional parameter scope in the previous 5.1.1 Authorization request, which indicates the scope of authorization to client access, such as an album, not Xiaoming's logs and other protected resources.
6. Sub: Optional. The unique identifier of the resource owner to which the token belongs, as defined by the JWT. That is, Xiaoming's unique identifier.
7. AUD: Optional. Token issued to WHO, JWT defined.
8. ISS: Optional. Token issuer, JWT definition.
9. Exp: Optional. Token expiration time, JWT definition.
10. IAT: Optional. ISS issues token time, JWT definition.
11. NBF: Optional. Tokens are not used before this time, and JWT is defined.
12. JTI: Optional. Token's unique identification, JWT definition.
13. Extension_field: You can extend related other properties yourself.

A large amount of information is optional information, and you can expand the required property information, from these attributes can be resolved in the above mentioned Access_token for the client is not transparent issues.

We notice that there are many properties that are part of the JWT definition, so what is this JWT? What is it that solves the problem?

4 JSON Web Token (JWT)

In summary, JWT is a standard protocol that defines a compact , self-contained , and non-tamper-proof mechanism for delivering data.

Let's look at a simple example first:

EyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Imxpbmlhbmh1aSJ9.hnOfZb95jFwQsYj3qlgFbUu1rKpfTE6 Azgxzideggtk

This is a bunch of strings that look like garbled characters. JWT consists of 3 parts: Header.payload.signature, each part by "." to separate.

4.1 Header

The header is a valid JSON, which usually contains two parts: the token type and the signature algorithm.

{  "alg": "HS256",  "Typ": "JWT"}

This JSON is base64 encoded by the 1th part of the eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.

4.2 Payload

This section represents the data that you really want to pass, including a set of claims, where JWT pre-defines some claim (2. Token metadata This section uses some of the cliam that are predefined by JWT). Refer to the reference link at the end of the article for what is claim.

{  "sub": "1234567890",  "name": "Linianhui"}

This JSON is Base64 encoded by the 2nd part of the eyjzdwiioiixmjm0nty3odkwiiwibmftzsi6imxpbmlhbmh1asj9.

4.3 Signature

This section is optional, because the previous header and payload sections are clear text, so the meaning of this part is to protect the information from tampering, and generate this part in the following way:

HMACSHA256 (  Base64urlencode (header) + "." +  Base64urlencode (payload),  secret)

The token generator uses the signature algorithm specified in the header to sign the "Header.payload" section, resulting in the 3rd part of the HNOFZB95JFWQSYJ3QLGFBUU1RKPFTE6AZGXZIDEGGTK, It is then combined into a full JWT string. The token consumer after getting token, use the same signature algorithm to generate the signature, to determine the header and payload part has not been tampered with, because the signature of the key is only the communication between the parties know, so you can ensure that this part of the information is not tampered with by a third party.

some claims of 4.4 JWT

Some cliam are predefined in the JWT specification, but are not required and are commonly used:

2. iss（Issuer签发者）。
4. sub（subject签发给的受众，在Issuer范围内是唯一的）。
6. AUD (audience receiver)
8. EXP (Expiration time expiration)
10. iat（Issued At签发时间）等等。

More complete list of some claim see: https://www.iana.org/assignments/jwt/jwt.xhtml

If these are still not sufficient for your own needs, you can customize some to use.

4.5 JWT Application Scenario

Because it uses Base64 to encode, it can be used safely in some ASCII -only places to pass information, such as the URL of the querystring.

For example, the user login, you can put some of the user's property information (user ID, whether the administrator, what permissions and so on can be disclosed information) with JWT encoding stored in a cookie, because of its self-contained nature, each time the server read to the cookie can be resolved to the current user's corresponding property information, Instead of having to query the database again. If you send a wasted bandwidth each time in a cookie, you can also use authorization:bearer <jwttoken> to attach to the request.

5 OAuth2 & JWT

Notice that we are in 2. Token metadata in this section, OAUTH2 returns the JSON for token metadata, and Access_token in OAuth2 is an opaque string to the client, we can put Access_ Token metadata information is encoded with JWT as the string content of the Access_token, so that it can be made transparent to the client.

For example, I have encountered the problem, when I use Access_token when there is no expiration I do not know, in fact, the need to help the "expires_in" To check, as well as its scope is what, also need additional to query, such as this Access_ Who is the user of token management, also need additional queries, with JWT, you can pack them in, such as:

{    "sub": "Linianhui",    "Scope": "1419356238",    "exp": 123456789,}

Then generate a JWT string like this EyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsaW5pYW5odWkiLCJzY29wZSI6IjE0MTkzNTYyMzgiLCJleHAiOjEyMzQ1Njc4OX0.ASu85ohH MSOHNXBJSJI4OKLSPLBJPS7TH0XW5-B4L1A as the value of Access_token, feel all of a sudden convenience of a lot of it.

6 Summary

OAuth2 did not provide a complete solution to the problem in RFC6749, but attached some related RFCs to solve these problems, in addition to the 2 problem points mentioned in this article, there are other places that can be optimized (such as service discovery: https:// tools.ietf.org/html/draft-ietf-oauth-discovery-06), from Post Response mode:http://openid.net/specs/ oauth-v2-form-post-response-mode-1_0.html), these points in the follow-up oidc of the article again to introduce it, interested can take a look at http://openid.net/connect/ Additional relevant extension standards for OAUTH2, which are also optional support for OIDC, as well as a draft oauth-related extension: https://datatracker.ietf.org/wg/oauth/charter/. Also in some scenarios, using JWT to make OAuth2 provide self-contained tokens is a very handy thing.

These are some of the personal understanding, if the error, please correct me!

7 References

JSON protocol: rfc7159-the JavaScript Object Notation (JSON) Data interchange Format

OAuth2 Extension Protocol:

Rfc7009-oauth 2.0 Token Revocation

Rfc7662-oauth 2.0 Token Introspection

Draft OAuth related extensions:

https://datatracker.ietf.org/wg/oauth/charter/

https://tools.ietf.org/wg/oauth/

JWT Related protocol families:

Rfc7515-json Web Signature (JWS)

Rfc7516-json Web Encryption (JWE)

Rfc7517-json Web Key (JWK)

Rfc7518-json Web Algorithms (JWA)

Rfc7519-json Web Token (JWT)

JWT Official site: Https://jwt.io

Claims:https://en.wikipedia.org/wiki/claims-based_identity

A set of claims:https://www.iana.org/assignments/jwt/jwt.xhtml registered by JWT

Blackheart Original link: https://www.cnblogs.com/linianhui/p/oauth2-extensions-protocol-and-json-web-token.html

[Certification Authority] 2.OAUTH2 Authorization (cont.) & JWT (JSON Web Token)