Original address: http://www.ibm.com/developerworks/cn/java/j-lo-oauth/index.html
Reference Blog: http://www.cnblogs.com/wangkewei/archive/2011/01/14/1935858.html
OAuth was co-sponsored by Blaine Cook, Chris Messina, Larry Halff and David Recordon to provide a secure, open standard for API access authorization.
OAuth-based authentication authorization has the following characteristics:
- Safety. The difference between OAuth and other licensing methods is that OAuth's authorization does not cause the consumer (Consumer) to touch the user's account information (such as user name and password), or that the consumer can request authorization for the user's resources without using the user's username and password.
- Open. Any consumer can use the OAuth Authentication Service, and any provider (service Provider) can implement its own OAuth authentication service.
- Simple. It is easy to understand and use, both by consumers and by service providers.
- The solution for OAuth is as shown.
The triangular relationship between users, consumers, and their service providers in the OAuth solution shown in 1: When a user needs Consumer to provide a service for it, the service involves having to obtain the user's protection resources from the service provider. OAuth Guarantee: Only if the user explicitly authorizes (step 4), the consumer can obtain the user's resources, and to serve the user.
At a macro level, OAuth works in the following ways:
- The consumer has established relationships with different service providers.
- The consumer shares a passphrase or a public key to the service provider, which is used by the service provider to confirm the identity of the consumer.
- The consumer redirects the user to the login page based on the service provider.
- The user logs in and tells the service provider that the consumer has access to his protected resources.
Before understanding the OAuth certification process, let's look at some basic terminology definitions for the OAuth protocol:
- Consumer Key: The consumer's identity uniquely identifies the service provider.
- Consumer Secret: Used to confirm the consumer's relationship to Consumer Key.
- Request token: Obtain a user-authorized solicitation token for exchanging Access tokens.
- Access Token: Used to obtain a protected resource for the user on the service provider.
- Token Secret: Used to confirm that the consumer has a relationship with the token (Request token and Access token).
OAuth Authentication Authorization Process
- consumption direction the OAuth service provider requests an unauthorized request Token.
- oauth the service provider has authenticated the consumer's legitimate request and issued it without user authorization. Request token and its corresponding token Secret.
- consumer uses the received Request Token, via URL To guide the user to the service provider, this step should be the behavior of the browser. Next, the user can authorize the request by entering the user name/password information on the service provider. Once the authorization is successful, go to the next step.
- The service provider directs the user back to the consumer through a URL, which is also the browser's behavior.
- oauth the service provider agrees to the consumer's request and issues Access Token to it and the corresponding Token Secret.
Generally speaking, in the OAuth technology system, the service provider needs to provide the following basic functions:
- 1th, achieve three service endpoints, namely: provide to obtain the unauthorized request token service address, obtain the user authorized Request token service address, and use authorized request token in exchange for access Toke N's service address.
- 2nd, provide the user authentication based on Form, so that the user can login to the service provider to make authorization.
- 3rd, authorized management, such as the user can revoke the authorization has been made at any time.
For consumers, the following basic functions are required:
Let's take a look at an example of using OAuth authentication
- 1th, obtain Customer Key/customer Secret from the service provider.
- 2nd, provide an HTTP-based communication mechanism with the service provider in exchange for related tokens.
In a traditional Web site application, if you want to import site B's contact list on site A, you need to enter your site B's user name and password information on site A. For example, you log in to Plaxo (https://www.plaxo.com), a contact management site, and when you want to import a Gmail contact list to Plaxo, you need to enter your Gmail username/password, as shown:
Here, Plaxo promises not to save your password in Gmail.
If you use OAuth authentication, the situation is different, and you do not need to expose your site B (playing the Service Provider role) The user name and password information to site A (the Consumer role). For example, you log on to the Http://lab.madgex.com/oauth-net/googlecontacts/default.aspx Web site:
Click on "Get my Google Contacts" and the browser will redirect you to Google and guide you to Google,
After the login is successful, you will see the graph
After you sign in to Google, click "Grant Access" and after authorizing lab.madgex.com, Lab.madgex.com will be able to get your contact list in Google.
In the example above, the site lab.madgex.com plays the role of Consumer, and Google is the Service provider,lab.madgex.com to get a contact list from Google using OAuth-based authentication.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Java application programming based on OAuth security protocol 1