Go serveur OAuth2

Ce service implémente la spécification OAuth 2.0 . Des extraits de la spécification sont inclus dans ce fichier README pour décrire les différents types de subventions. Veuillez lire la spécification complète pour plus d'informations.

OAuth 2.0

Authentification du client

http://tools.ietf.org/html/rfc6749#section-3.2.1

Les clients doivent s'authentifier avec les informations d'identification du client (ID client et secret) lors de l'émission de demandes au  point de terminaison /v1/oauth/tokens. L'authentification HTTP de base doit être utilisée.

Types de subventions

Code d'autorisation

http://tools.ietf.org/html/rfc6749#section-4.1

Le type d'octroi de code d'autorisation est utilisé pour obtenir à la fois des jetons d'accès et des jetons d'actualisation et est optimisé pour les clients confidentiels. Puisqu'il s'agit d'un flux basé sur la redirection, le client doit être capable d'interagir avec l'agent utilisateur du propriétaire de la ressource (généralement un navigateur Web) et capable de recevoir des demandes entrantes (via la redirection) du serveur d'autorisation.

+----------+

| 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)

Le client lance le flux en dirigeant l'agent utilisateur du propriétaire de la ressource vers le point de terminaison d'autorisation. Le client inclut son identifiant client, la portée demandée, l'état local et un URI de redirection vers lequel le serveur d'autorisation renverra l'agent utilisateur une fois que l'accès est accordé (ou refusé).

http://localhost:8080/web/authorize?client_id=test_client_1&redirect_uri=https%3A%2F%2Fwww.example.com&response_type=code&state=somestate&scope=read_write

Le serveur d'autorisation authentifie le propriétaire de la ressource (via l'agent utilisateur).

Capture d'écran de la page de connexionCapture d'écran de la page de connexion

Le serveur d'autorisation établit ensuite si le propriétaire de la ressource accorde ou refuse la demande d'accès du client.

Capture d'écran de la page d'autorisationCapture d'écran de la page d'autorisation

Si la demande échoue en raison d'un URI de redirection manquant, invalide ou incompatible, ou si l'identifiant client est manquant ou invalide, le serveur d'autorisation DEVRAIT informer le propriétaire de la ressource de l'erreur et NE DOIT PAS rediriger automatiquement l'agent utilisateur vers la redirection invalide URI.

Si le propriétaire de la ressource refuse la demande d'accès ou si la demande échoue pour des raisons autres qu'un URI de redirection manquant ou non valide, le serveur d'autorisation informe le client en ajoutant le paramètre d'erreur au composant de requête de l'URI de redirection.

https://www.example.com/?error=access_denied&state=somestate

En supposant que le propriétaire de la ressource accorde l'accès, le serveur d'autorisation redirige l'agent utilisateur vers le client en utilisant l'URI de redirection fourni précédemment (dans la demande ou lors de l'enregistrement du client). L'URI de redirection comprend un code d'autorisation et tout état local fourni précédemment par le client.

https://www.example.com/?code=7afb1c55-76e4-4c76-adb7-9d657cb47a27&state=somestate

Le client demande un jeton d'accès au point de terminaison de jeton du serveur d'autorisation en incluant le code d'autorisation reçu à l'étape précédente. Lors de la demande, le client s'authentifie auprès du serveur d'autorisation. Le client inclut l'URI de redirection utilisé pour obtenir le code d'autorisation pour la vérification.

curl --compressed -v localhost:8080/v1/oauth/tokens \

        -u test_client_1:test_secret \

        -d "grant_type=authorization_code" \

        -d "code=7afb1c55-76e4-4c76-adb7-9d657cb47a27" \

        -d "redirect_uri=https://www.example.com"

 

Le serveur d'autorisation authentifie le client, valide le code d'autorisation et s'assure que l'URI de redirection reçu correspond à l'URI utilisé pour rediriger le client auparavant. S'il est valide, le serveur d'autorisation répond avec un jeton d'accès et, éventuellement, un jeton d'actualisation.

{

  "user_id": "1",

  "access_token": "00ccd40e-72ca-4e79-a4b6-67c95e2e3f1c",

  "expires_in": 3600,

  "token_type": "Bearer",

  "scope": "read_write",

  "refresh_token": "6fd8d272-375a-4d8a-8d0f-43367dc8b791"

}

Implicite

http://tools.ietf.org/html/rfc6749#section-4.2

Le type d'octroi implicite est utilisé pour obtenir des jetons d'accès (il ne prend pas en charge l'émission de jetons d'actualisation) et est optimisé pour les clients publics connus pour exploiter un URI de redirection particulier. Ces clients sont généralement implémentés dans un navigateur à l'aide d'un langage de script tel que JavaScript.

Puisqu'il s'agit d'un flux basé sur la redirection, le client doit être capable d'interagir avec l'agent utilisateur du propriétaire de la ressource (généralement un navigateur Web) et capable de recevoir des demandes entrantes (via la redirection) du serveur d'autorisation.

Contrairement au type d'octroi de code d'autorisation, dans lequel le client effectue des demandes distinctes d'autorisation et de jeton d'accès, le client reçoit le jeton d'accès à la suite de la demande d'autorisation.

Le type d'octroi implicite n'inclut pas l'authentification du client et repose sur la présence du propriétaire de la ressource et l'enregistrement de l'URI de redirection. Étant donné que le jeton d'accès est codé dans l'URI de redirection, il peut être exposé au propriétaire de la ressource et à d'autres applications résidant sur le même appareil.

+----------+

| 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 |

|         |

+---------+

Le client lance le flux en dirigeant l'agent utilisateur du propriétaire de la ressource vers le point de terminaison d'autorisation. Le client inclut son identifiant client, la portée demandée, l'état local et un URI de redirection vers lequel le serveur d'autorisation renverra l'agent utilisateur une fois que l'accès est accordé (ou refusé).

http://localhost:8080/web/authorize?client_id=test_client_1&redirect_uri=https%3A%2F%2Fwww.example.com&response_type=token&state=somestate&scope=read_write

Le serveur d'autorisation authentifie le propriétaire de la ressource (via l'agent utilisateur).

Capture d'écran de la page de connexionCapture d'écran de la page de connexion

Le serveur d'autorisation établit ensuite si le propriétaire de la ressource accorde ou refuse la demande d'accès du client.