Laravel study notes (26) laravel6 Authentication and Authorization (OAuth 2.0 four modes interpretation)

Reference: Reference Site

1. Authorization code mode (for the front and rear end of the separator)

This approach is most commonly used process, safety is the highest, it is suitable for those who have back-end Web application. Authorization code transmitted through the front, the token is stored at the rear end, and all communications with the server resources are completed at the rear end . Such separate front and rear ends, the token can avoid leakage.

Generally applies to third-party sites through micro letter, QQ, Github is this landing mode

Web Application Developer's Guide landing micro letter

question: Why use authorization codes
reasons: to avoid token leak

Q: Why not just return authorization code to the B station
reason: more authorization codes and returns to the station B, B station can not determine which code belongs to which user authorization

2. Hidden (not suitable for third-party background, not recommended)

Some are pure Web application front-end application, not the back end. At this time can not be used in the above manner, the token must be stored at the front end. RFC 6749 was subject to a second way, allowing the token issued directly to the front end. In this way there is no intermediate step of the authorization code, so called (authorization code) "hidden" (implicit).

The first step, providing a link to station B requires the user to jump to the micro-channel, an authorized user to use the data to the B station.

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

The second step, the user jump to the micro-channel go to the website, after logging station B agreed to give authorization. Thereafter, the micro-channel jump jump back redirect_uri parameter specifies the URL, and the URL token as a parameter passed to the B station.
The third step, B station holding the token to user resources obtained micro-letter

Note: in this way the token directly to the front, is very safe. Therefore, only less demanding scene for some security and validity of the token must be very short, usually it is during the session (session) effective, turn off the browser, the token becomes ineffective.

3. Password (the user is extremely trusted third party)

If you use a high degree of trust, RFC 6749 also allows the user to user name and password, and tell the application. The application on the use of your password, token applications, this approach is called "code-style" (password)

Use summary: Laravel's passport password authorization mode complete API certification

From the article it seems, in fact, the password mode can be used in the case of complete separation of the front and rear end. In this case the front end (or just a Postman) is similar to the third-party server (B station), a request to back-end resources (authorized server) (micro-channel) via the API.
It can also be used at the same company for different products. Such as Weibo and Sina-mail, as long as the other would not have landed a landing.

The first step, B station requires the user to provide a user name and password of the micro channel. After get, B station directly to the micro-channel request token
(Postman account password input by the user, and then directly to the request token API)

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

The second step, through the micro-channel authenticate directly given token. Note that this case does not need to jump, but the data which the token on JSON, as HTTP response, B station and therefore get the token.
(After the verification, API returns a token to the Postman)
a third step, B station holding the token to user resources obtained micro-letter

4. Certificated (client mode, not suitable for third-party front-end, the whole process without user involvement)

Last approach is certificated (client credentials), a command line application does not apply to the front end, i.e., at a command line request token

The first step, B station requesting application on the command line to the micro channel.

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

The second step, after the verification by the micro-channel site, the token returns directly.
The third step, B station holding the token to get micro channel resources required

This gives us the token is for third-party applications, but not for the user, that it is possible to multiple users share the same token .