从0开始构建一个Oauth2Server服务 11
#

授权 Authorization
#

授权界面是用户在授予应用程序访问其帐户时看到的屏幕。以下部分介绍了如何构建授权屏幕、界面中包含哪些组件以及如何最好地向最终用户展示界面。

实施 OAuth 服务器时，您正在使开发人员社区能够构建利用您的平台的应用程序，允许应用程序访问并可能修改私人用户内容，或代表用户行事。因此，您需要确保为用户提供尽可能多的信息来保护他们的帐户，并确保他们了解应用程序正在使用他们的帐户做什么。

Authorization Request
#

客户端会将用户的浏览器定向到授权服务器以开始 OAuth 过程。客户端可以使用授权代码授权类型或隐式授权。除了由参数指定的授权类型外response_type，请求还将具有许多其他参数来指示请求的细节。

服务器端应用程序描述了客户端如何为您的服务构建授权 URL。授权服务器第一次看到用户将是这个授权请求，用户将被定向到具有客户端设置的查询参数的服务器。此时，授权服务器需要验证请求并呈现授权界面，允许用户批准或拒绝请求。

请求参数
#

以下参数用于开始授权请求。例如，如果授权服务器 URL 是https://authorization-server.com/auth，则客户端将创建如下所示的 URL 并将用户的浏览器定向到它：

https://authorization-server.com/auth?response_type=code
&client_id=29352735982374239857
&redirect_uri=https://example-app.com/callback
&scope=create+delete
&state=xcoivjuywkdkhvusuye3kch

响应类型
#

response_type将设置为code，表示应用程序希望在成功时收到授权码。

`client_id`
#

是client_id应用程序的公共标识符。

`redirect_uri`（选修的）
#

redirect_uri规范不要求它，但您的服务应该需要它。此 URL 必须与开发者在创建应用程序时注册的 URL 之一匹配，如果不匹配，授权服务器应拒绝该请求。

`scope`（选修的）
#

该请求可能具有一个或多个范围值，指示应用程序请求的额外访问。授权服务器需要向用户显示请求的范围。

`state`（受到推崇的）
#

state应用程序使用该参数来存储特定于请求的数据和/或防止 CSRF 攻击。授权服务器必须将未修改的状态值返回给应用程序。

PKCE
#

如果授权服务器支持 PKCE 扩展（在 PKCE中描述），那么code_challenge和code_challenge_method参数也将存在。在发布授权代码和发布访问令牌之间，授权服务器必须记住这些。

验证授权请求
#

授权服务器必须首先验证client_id请求中的是否对应于有效的应用程序。

如果您的服务器允许应用程序注册多个重定向 URL，则有两个步骤来验证重定向 URL。如果请求包含redirect_uri参数，服务器必须确认它是该应用程序的有效重定向 URL。redirect_uri如果请求中没有参数，并且只注册了一个 URL，则服务器使用之前注册的重定向 URL。否则，如果请求中没有重定向 URL，并且没有注册重定向 URL，则这是一个错误。

如果client_id无效，服务器应立即拒绝请求并向用户显示错误，而不是将用户重定向回应用程序。