在阅读使用JWT保护应用程序时，通常会说客户端最初从服务器获取令牌，然后将此令牌与每个请求一起发送给API。
一旦有了令牌，这种方法效果很好。据我所知，传输令牌的默认方式是使用HTTP头，即带有承载的身份验证作为令牌的前缀作为值。
但是 - 最初是如何获得令牌的默认方式？在示例中，您经常会看到这只是对HTTP端点的简单请求，然后返回JSON。但我想知道是否有更多的标准工作流程，例如描述了该端点的名称，如OAuth2？
任何提示？
答案 0 :(得分：17)
JWT是一种令牌格式，用于OAuth2和OpenID Connect等安全协议。
如何从授权服务器获取令牌取决于您使用的授权流程。
OAuth 2.0中定义了4个授权流程，用于不同的客户端和用途。
此授权适用于Web应用程序。用户的浏览器被重定向（HTTP 302）到授权服务器。授权服务器负责对用户进行身份验证（通过用户名/密码，智能卡，双因素身份验证等）。
然后，授权服务器使用代码将浏览器重定向回Web应用程序中的预先注册的端点。然后，Web应用程序使用自己的凭据（客户端ID和客户端密钥）和授权代码从授权服务器请求访问令牌。
授权服务器向Web应用程序返回访问令牌和刷新令牌。请注意，浏览器（不受信任）从不会看到访问令牌。只有Web应用程序（受信任）才能访问访问令牌和刷新令牌。
此授权很难从其他客户端使用，因为它基于HTTP重定向。
此授权用于不受信任的客户端，例如JavaScript应用程序或第三方移动客户端（您从应用商店下载的客户端）。
它还将浏览器（或浏览器控件）重定向到授权服务器，但是在成功进行身份验证后，它不会将代码返回到浏览器，而是直接返回访问令牌。由于客户端不受信任，因此授权不会返回刷新令牌。访问令牌需要存储在某个地方，并且容易受到XSS攻击。
即使您没有获得刷新令牌，一些实现确实提供了一种方法来通过与隐藏的IFRAME中的授权服务器通信并使用cookie来授权服务器本身来获取新的访问令牌。
此授权适用于受信任的客户端，例如桌面应用程序或具有安全存储功能的第一方移动应用程序。客户端应用程序向用户（资源所有者）询问其用户名/密码，然后将其发送到授权服务器以获取访问令牌和刷新令牌。
一旦客户端具有访问令牌，它就可以丢弃密码，因为它可以使用刷新令牌来获取新的访问令牌。这使它比基本身份验证更安全。
此授权不依赖于浏览器重定向，可以从任何可以执行HTTP请求的应用程序中轻松使用。
此授权用于验证客户端（应用程序）而不是客户端用户。
在这种情况下，客户端将其客户端ID和密码直接提交给授权服务器以获取访问和刷新令牌。
所以基本上前两个授权依赖于类似浏览器的功能（HTTP重定向，HTML登录页面），其他两个授权只需要一个HTTP堆栈来与授权服务器通信。
答案 1 :(得分：-1)
每个OAuth2服务器都有自己的端点。客户端可以使用http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata等发现协议发现相关端点的名称。