在阅读使用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等发现协议发现相关端点的名称。