Change of "Turn" OAuth

Source: Internet
Author: User
Tags oauth

Original address: http://huoding.com/2011/11/08/126

Last year I wrote a "OAuth thing" and gave a brief introduction to OAuth, and today I'm going to write some details to illustrate how OAuth changes from 1.0 to 1.0a and then to 2.0.

OAuth1.0

Before OAuth was born, the standard protocol for Web security was only OpenID, but it focused on validation, who's problem, not authorization, what's the problem. Fortunately, private agreements such as Flickrauth and googleauthsub have made a number of useful attempts at authorization, thus laying the groundwork for the birth of OAuth.

OAuth1.0 defines three roles: User, Service Provider, Consumer. How to understand? Suppose we do a SNS, it has a function, you can let members to their Google contacts on the SNS, then the member is User,google service Providere, and SNS is consumer.

 +----------+                                           +----------+ |          |--(a)-obtaining A Request Token--------->|          | |                                           |          |          | |          |<-(B)-Request Token----------------------|          | |       |          (Unauthorized) |          | |                                           |          |          | |      |          +--------+                           |          | |       |>-(C)-|          -+-(C)-Directing---------->|          | |      |       |          -+-(D)-User authenticates->|          | |      |        |      | +----------+         | Service | |      Consumer | |      user-|          |         | |          Provider | |      | |   Agent-+-(D)->|         User |          |          | |      |        |      |          |         |          |          | |      |        |      |          +----------+         |          | |       |<-(E)-|-+-(E)-Request Token------<|          | |      |          +--------+ (Authorized) |          | |                                           |          |          | |          |--(F)-Obtaining a Access Token---------->|          | |                                           |          |          | |          |<-(G)-Access Token-----------------------| | +----------+                                           +----------+

Tidbits: OAuth1.0 RFC no ASCII flowchart, so I knocked hundreds of down the keyboard himself drew a, after the Netizen hint, Emacs can easily get the ASCII map: Emacs Screencast:artist Mode,vim Of course, can also be done, But to use a plugin: Drawit, unfortunately my keyboard is broken.

Consumer application Request Token (/oauth/1.0/request_token):

Oauth_consumer_keyoauth_signature_methodoauth_signatureoauth_timestampoauth_nonceoauth_version

Service provider returns request Token:

Oauth_tokenoauth_token_secret

Consumer redirect user to service Provider (/oauth/1.0/authorize):

Oauth_tokenoauth_callback

Service provider redirect user to consumer after authorization:

Oauth_token

Consumer Apply for Access Token (/oauth/1.0/access_token):

Oauth_consumer_keyoauth_tokenoauth_signature_methodoauth_signatureoauth_timestampoauth_nonceoauth_version

Service provider returns Access Token:

Oauth_tokenoauth_token_secret

...

Note: Throughout the operating process, it is important to note that two tokens are involved, namely request token and access token, where request token involves two states, namely, unauthorized and authorized.

oauth1.0a

OAuth1.0 There are security vulnerabilities, details: Explaining the OAuth Session fixation Attack, and this: how the OAuth security Battle is Won, Open Web styl E.

In simple terms, this is a session-hardening attack, unlike a common session hijacking attack, in which an attacker initializes a legitimate session and then convinces the user to complete subsequent operations on the session to achieve the purpose of the attack. Reflected on the OAuth1.0, the attacker would first request token, then convince the user to authorize the request token, and then for the use of the callback address, there are several attack methods:

    • If the service provider does not restrict the callback address (the application settings do not qualify the root domain), then the attacker can set the oauth_callback to their own URL, and when the user completes the authorization, this URL will naturally get access to the user Token.
    • If the consumer does not use the callback address (desktop or mobile program), but instead through the user manual copy paste request token to complete the authorization, then there is a competitive relationship, as long as the attacker after user authorization, Rob before user to initiate a request, You can get access Token for the user.

In order to fix the security problem, oauth1.0a appeared (RFC5849), mainly modified the following details:

    • Consumer must pass Oauth_callback when applying for request token, and consumer does not need to pass oauth_callback when applying for access token. Through the timing of the pre-oauth_callback, let Oauth_callback participate in the signature, thus avoiding the attacker to impersonate Oauth_callback.
    • When the Service provider redirects user to consumer after obtaining the user authorization, it returns Oauth_verifier, which is used during consumer application for access token. The attacker could not guess its value.

Consumer application Request Token (/oauth/1.0a/request_token):

Oauth_consumer_keyoauth_signature_methodoauth_signatureoauth_timestampoauth_nonceoauth_versionoauth_callback

Service provider returns request Token:

Oauth_tokenoauth_token_secretoauth_callback_confirmed

Consumer redirect user to service Provider (/oauth/1.0a/authorize):

Oauth_token

Service provider redirect user to consumer after authorization:

Oauth_tokenoauth_verifier

Consumer Apply for Access Token (/oauth/1.0a/access_token):

Oauth_consumer_keyoauth_tokenoauth_signature_methodoauth_signatureoauth_timestampoauth_nonceoauth_versionoauth _verifier

Service provider returns Access Token:

Oauth_tokenoauth_token_secret

Note: When service provider returns a request token, the returned oauth_callback_confirmed is included to indicate whether the service provider supports the oauth1.0a version.

...

In the signature parameter, Oauth_timestamp represents the time that the client initiated the request, such as non-validation, which poses a security issue.

Before discussing Oauth_timestamp, talk about Oauth_nonce, which is used to prevent replay attacks, Service provider should verify uniqueness, but saving all oauth_nonce is not realistic, Therefore, it is generally only stored for a period of time (such as the last hour) of data.

If the oauth_timestamp is not verified, then once the attacker intercepts a request, as long as the time limit is reached, oauth_nonce will be able to re-send the request as it is again, and the signature will pass naturally, it is a legitimate request, so the service Provider must verify that the deviation of the oauth_timestamp and system clocks is within an acceptable range (say 10 minutes) so that replay attacks are completely eliminated.

...

You need to talk about how the desktop or mobile app should use oauth1.0a. This kind of application usually does not have the service side, cannot set the Web form the Oauth_callback address, at this time should set it to OOB (Out-of-band), when the user chooses authorizes, the service provider displays the PIN code on the page (namely Oauth_ verifier) and directs the user to paste it into the application to complete the authorization.

One question is how does the app open the user authorization page? It is easy to think of the practice is to use an embedded browser, said it is a wrong approach may be a bit biased, but it is at least a user unfriendly approach, because once the browser embedded in the program, the user entered the user name password is likely to be monitored, the user-friendly approach should be to open a new window, Pop-up the system's default browser to allow the user to complete the authorization process in a trustworthy context.

However, this way requires the user to manually switch between the browser and the application, in order to complete the authorization process, to some extent, the impact of the user experience, fortunately, there are some other techniques to circumvent this problem, one of the effective way is monitor web-browser Title-bar, Simply put, the operating system generally provides the appropriate API to enable the application to listen to all the Windows on the desktop title, the application once found that a window title conforms to the predefined format, it can be considered as the PIN code we want to complete the authorization process without user involvement. Google supports this approach and has information that specifically describes the details: auto-detecting Approval (note: Wall!) )。

It is also important to note that for desktop or mobile applications, Consumer_key and Consumer_secret are usually stored directly in the application, so for an attacker, in theory, they can be solved by means of anti-compilation. Then through Consumer_key and Consumer_secret signed a forged request, and in the request to the Oauth_callback set to their own control URL, to defraud the user authorization. To block this type of problem, the Service provider needs to force the developer to pre-define the callback address: If the predefined callback address is URL-like, you need to verify that the callback address in the request and the predefined callback address are the same as the primary domain, if the pre-defined callback address is OOB mode, The request is blocked by a URL callback.

OAuth2.0

OAuth1.0 Although there is no problem in the security patch, but there are other shortcomings, the most important is the following two points: one, the signature logic is too complex, not friendly to the developer; second, the authorization process is too simple, in addition to Web applications, desktop, mobile applications are not friendly.

To compensate for these short plates, OAuth2.0 made the following changes:

First, remove the signature, use SSL (HTTPS) to ensure security, all tokens no longer have the corresponding secret exist, which also directly lead to OAuth2.0 incompatible with the old version.

Secondly, different authorization processes are used for different situations, and the new version provides four authorization processes, which can be selected according to the objective situation, compared to the old version with only one authorization process.

Before we elaborate on the authorization process, we need to look at the roles in OAuth2.0:

OAuth1.0 defines three roles: User, Service Provider, Consumer. OAuth2.0 defines four roles: Resource Owner, Resource server, Client, Authorization server:

    • Resource Owner:user
    • Resource Server:service Provider
    • Client:consumer
    • Authorization Server:service Provider

That is, OAuth2.0 the service provider roles in the original OAuth1.0 into the resource server and authorization server two roles, which interact with authorization when authorized Server, which interacts with resource server when requesting resources, and of course, sometimes they are merged.

Let's look at the four licensing processes OAuth2.0 provides:

Authorization Code

Available range: This type is available for applications that have a service side and is the closest way to the old version.

 +----------+ |   Resource | |          Owner | | |     +----------+      ^      |         (B) +----|-----+ Client Identifier +---------------+ |               -+----(A)--& redirection URI---->|  | |                                 user-| |  Authorization | |     Agent-+----(B)--User Authenticates--->|          Server | |                                 |               |         | |               -+----(C)--Authorization Code---<| |    +-|----|---+                                 +---------------+   |                                         |      ^ V (A) (C) |   |    |                                         |      |   |      ^ V | |      +---------+                                      |         | |  |>---(D)--Authorization Code---------' | |          Client |         & Redirection URI | |                                  |           | | |<---(E)-----Access Token-------------------' +---------+ (w/optional Refresh token)

Client sends a request to authorization server (/oauth/2.0/authorize):

Response_type = Codeclient_idredirect_uriscopestate

Authorization server returns Authorization Code to client after resource owner authorization:

Codestate

Client sends a request to authorization server (/oauth/2.0/token):

Grant_type = Authorization_codecodeclient_idclient_secretredirect_uri

Authorization server returns access Token to client after resource owner authorization:

Access_tokentoken_typeexpires_inrefresh_token

Description: The basic process is to take authorization code for access tokens.

Implicit Grant

Available range: This type can be used for applications that do not have a service end, such as JavaScript applications.

 +----------+ |  Resource | |          Owner | | |     +----------+      ^      |         (B) +----|-----+ Client Identifier +---------------+ |               -+----(A)--& redirection URI--->|  | |                                user-| |  Authorization | |     Agent-|----(B)--User authenticates-->|          Server | |                                |               |          | |               |<---(C)---redirection URI----<|          | |          |          With Access Token +---------------+ |            |          In Fragment |                                |          +---------------+ |   |----(D)---redirection URI---->|          web-hosted | |          |     Without Fragment |          Client | |                                |    |     Resource | |               (F) |<---(E)-------Script---------<|          | |                                |    +---------------+ +-|--------+   |  | (A) (G) Access Token  |   |         ^ v +---------+ |  | |         Client | | | +---------+

Client sends a request to authorization server (/oauth/2.0/authorize):

Response_type = Tokenclient_idredirect_uriscopestate

Authorization server returns access Token to client after resource owner authorization:

Access_tokentoken_typeexpires_inscopestate

Note: There is no server application, its information can only be saved on the client, if the use of Authorization code authorization method, can not guarantee the security of Client_secret. BTW: Do not return refresh Token.

Resource Owner Password Credentials

Available range: This type is available regardless of whether there is a server or not.

+----------+ | Resource | |  Owner   | |          | +----------+      v      |    Resource Owner     (A) Password Credentials      |      V +---------+                                  +---------------+ |         | >--(B)----Resource Owner------->|               | |         |         Password Credentials     | Authorization | | Client  |                                  |     Server    | |         | <--(C)----Access Token---------<|               | |         |    (w/optional Refresh Token)   |               | +---------+                                  +---------------+

Clien requests to Authorization Server (/oauth/2.0/token):

Grant_type = Passwordusernamepasswordscope

Authorizationserver returns Accesstoken to the client:

Access_tokentoken_typeexpires_inrefresh_token

Description: Because of the user name and password involved, this authorization type is only available for trusted applications.

Client Credentials

Available range: This type is available regardless of whether there is a server or not.

+---------+                                  +---------------+ |         |                                  |               | |         | >--(A)-Client Authentication--->| Authorization | | Client  |                                  |     Server    | |         | <--(B)----Access Token---------<|               | |         |                                  |               | +---------+                                  +---------------+

Client sends a request to authorization server (/oauth/2.0/token):

Grant_type = Client_credentialsclient_idclient_secretscope

Authorization server returns access Token to client:

Access_tokentoken_typeexpires_in

Description: This authorization type only applies to obtaining public information unrelated to the user. BTW: Do not return refresh Token.

...

The

process involves two tokens, namely access token and refresh token. Typically, access tokens have a shorter validity period, and the refresh token is valid for a longer period of time, so that when access token fails, it needs to refresh the valid access token with refresh token:

 +--------+                                         +---------------+ |               |--(A)-------Authorization Grant------->|        | |                                         |               |        | |               |<-(B)-----------Access Token-----------|        | |               |               & Refresh Token |        | |                                         |               |        | |                            |               +----------+ |        | |          |--(C)----Access Token---->|               | |        | |                            |          |               | |        | | |<-(D)-Protected Resource--| Resource | | Authorization | |                            Client |  |     Server | |        Server | |          |--(E)----Access Token---->|               | |        | |                            |          |               | |        | |          |<-(F)-Invalid Token Error-|               | |        | | |                           +----------+ |        | |                                         |               |        | |               |--(G)-----------Refresh Token--------->|        | |                                         |               |        | |               |<-(H)-----------Access Token-----------| | +--------+ & Optional Refresh Token +---------------+

Client sends a request to authorization server (/oauth/2.0/token):

Grant_type = Refresh_tokenrefresh_tokenclient_idclient_secretscope

Authorization server returns access Token to client:

Access_tokenexpires_inrefresh_tokenscope

...

But not all of us voted for OAuth2.0, so you can look at it: is OAuth 2.0 harmful to the Web?

This entry was published by Lao Wang in the technical category and tagged with the oauth tag. Add a pinned link to your Favorites folder.

Change of "Turn" OAuth

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.