OAuth的授权类型

OAuth的授权类型

OAuth定义了几种授权类型。每个授权都是一个不同的授权流,可以在不同的情况下使用。例如,你与网页交互以获得访问权限的方式可能与与智能灯泡交互的方式不同。

  1. 授权码模式(Authorization Code Grant)
  • 特点:最为复杂但安全系数最高,适用于有后端的Web应用。
  • 流程:
    • 客户端引导资源拥有者到授权服务器的授权端点。
    • 资源拥有者同意授权,授权服务器返回授权码给客户端。
    • 客户端使用授权码、客户端ID和客户端密钥向授权服务器请求访问令牌。
    • 授权服务器验证后返回访问令牌给客户端。
  • 安全性:前后端分离,避免令牌泄漏。
  1. 简化模式/隐式模式(Implicit Grant)
  • 特点:适用于没有后端的纯前端应用,跳过了授权码这一步。
  • 流程:
    • 客户端引导资源拥有者到授权服务器的授权端点。
    • 资源拥有者同意授权,授权服务器直接返回访问令牌给客户端(通过URL的哈希片段或重定向)。
  • 安全性:由于访问令牌直接返回给客户端,安全性相对较低。
  1. 密码模式(Resource Owner Password Credentials Grant)
  • 特点:资源拥有者将其用户名和密码直接交给客户端,客户端使用这些信息向授权服务器请求访问令牌。
  • 流程:
    • 客户端直接从资源拥有者处获取用户名和密码。
    • 客户端使用用户名、密码、客户端ID和客户端密钥向授权服务器请求访问令牌。
    • 授权服务器验证后返回访问令牌给客户端。
  • 安全性:由于客户端直接处理用户名和密码,存在安全风险,不推荐使用。
  1. 客户端凭据模式(Client Credentials Grant)
  • 特点:适用于客户端请求受保护资源的情况,无需资源拥有者的直接授权。
  • 流程:
    • 客户端使用其客户端ID和客户端密钥向授权服务器请求访问令牌。
    • 授权服务器验证后返回访问令牌给客户端。
  • 安全性:客户端ID和客户端密钥需要妥善保管,防止被滥用。
  1. Authorization code grant with Proof Key for Code Exchange (PKCE)
    Authorization Code Grant结合Proof Key for Code Exchange (PKCE)是一种增强OAuth 2.0授权码模式安全性的方法。PKCE主要是为移动设备应用和本地应用创建的,用于减少公共客户端的授权码拦截攻击。
  • 背景
    OAuth 2.0的授权码模式是一种适用于机密客户端(如Web服务器应用)的授权流程,具有较高的安全性。但是,对于公共客户端(如单页应用、移动应用),由于无法安全地存储客户端密钥,因此直接使用授权码模式存在安全风险。PKCE就是为了解决这一问题而提出的。

  • PKCE的核心概念

    • code_verifier:客户端生成的一个随机字符串,用于生成code_challenge。客户端必须安全地存储这个值,因为它将用于在令牌端点验证code_challenge。
    • code_challenge:code_verifier的转换形式,通常使用SHA256哈希算法对code_verifier进行哈希处理,并进行Base64 URL编码得到。code_challenge被发送到授权服务器,用于生成授权码。
  • 流程

    • 客户端生成code_verifier和code_challenge:客户端首先生成一个随机的code_verifier,并使用SHA256哈希算法和Base64 URL编码生成code_challenge。
    • 客户端请求授权码:客户端将用户重定向到授权服务器的授权端点,并在请求中包含code_challenge和code_challenge_method(指定用于生成code_challenge的哈希算法,如S256)。
    • 用户授权:用户在授权页面上输入用户名和密码,并同意授权。
    • 授权服务器返回授权码:授权服务器验证用户身份和授权请求后,生成一个授权码,并将它返回给客户端(通常通过重定向的方式)。
    • 客户端请求访问令牌:客户端使用授权码、code_verifier、客户端ID和其他必要的参数向授权服务器的令牌端点请求访问令牌。
    • 授权服务器验证并返回访问令牌:授权服务器验证授权码、code_verifier和其他参数的有效性后,返回访问令牌给客户端。
  • 安全性分析

    • 由于code_verifier是客户端生成的随机字符串,并且只在客户端和授权服务器之间传输code_challenge(而不是code_verifier本身),因此即使攻击者截获了code_challenge,也无法直接获取到code_verifier。
    • 当客户端在令牌端点使用授权码和code_verifier请求访问令牌时,授权服务器会验证code_challenge是否与之前生成的授权码相对应,从而确保只有真实的客户端才能获得访问令牌。

Authorization Code Grant结合PKCE为OAuth 2.0的授权码模式提供了额外的安全性保障,特别适用于公共客户端场景。通过引入code_verifier和code_challenge这两个元素,PKCE有效地防止了授权码被恶意截获并滥用的风险。

  1. Refresh token grant
    Refresh token grant 是在OAuth 2.0等认证和授权框架中用于获取新的访问令牌(access token)的一种机制。
  • 定义与用途:
    • Refresh token是一种特殊的令牌,用于在访问令牌(access token)过期后,从认证服务器获取新的访问令牌,而无需用户再次进行身份验证(如重新输入用户名和密码)。
    • 它的主要目的是延长用户的会话时间,提高用户体验,并减少频繁的身份验证需求。
  • 工作流程:
    • 当客户端首次通过用户身份验证从认证服务器获取访问令牌时,通常也会同时获得一个refresh token。
    • 当访问令牌过期时,客户端可以使用refresh token向认证服务器发送请求,以获取一个新的访问令牌。
    • 在发送请求时,客户端需要提供特定的参数,如grant_type(值为"refresh_token"),以及之前获得的refresh token。
    • 认证服务器验证refresh token的有效性后,会返回一个新的访问令牌(以及可能的一个新的refresh token)。
  • 安全性考虑:
    • 由于refresh token允许客户端在访问令牌过期后继续访问受保护的资源,因此其安全性至关重要。
    • Refresh token应该被妥善存储,避免被未经授权的第三方获取。
    • 一些实现还会限制refresh token的使用次数或时间,以减少潜在的安全风险。
  • 实现细节:
    • 在具体的实现中,客户端和认证服务器之间的通信通常使用HTTPS协议,以确保数据在传输过程中的安全性。
    • 认证服务器需要能够验证客户端的身份,并确保只有经过授权的客户端才能使用refresh token。
    • 客户端在发送请求时,可能需要提供额外的信息(如客户端ID和客户端密钥),以证明其身份。
  • 优点与局限性:
    • 优点:提高了用户体验,减少了频繁的身份验证需求;同时,由于使用了HTTPS和身份验证机制,提高了安全性。
    • 局限性:如果refresh token被泄露,恶意用户可能会利用它来获取访问令牌,并访问受保护的资源。因此,需要采取适当的安全措施来保护refresh token。

综上所述,Refresh token grant是一种在OAuth 2.0等认证和授权框架中用于获取新的访问令牌的重要机制。它通过允许客户端在访问令牌过期后使用refresh token来获取新的访问令牌,从而延长了用户的会话时间,提高了用户体验。然而,为了确保安全性,需要采取适当的安全措施来保护refresh token。

  1. Device authorization grant
    Device Authorization Grant(设备授权授予)是OAuth 2.0(及其后续版本)中定义的一种授权模式,特别适用于无法直接进行用户交互或输入受限的设备,如智能电视、IoT设备等。以下是关于Device Authorization Grant的详细解释:
  • 定义
    Device Authorization Grant(设备授权授予)或Device Flow,允许终端用户或硬件(如智能电视、IoT设备等)通过辅助设备(如智能手机或平板电脑)进行身份验证和授权。这种授权模式特别适用于那些无法直接进行复杂用户交互或缺乏传统输入方式的设备。

  • 工作流程

    • 设备发起授权请求:
      • 客户端设备(即无法直接进行用户交互的设备)向认证服务器的设备授权端点发送授权请求。
      • 请求中通常包含客户端ID(client_id)和所需的作用域(scope,可选)。
    • 用户验证与授权:
      • 认证服务器响应请求,生成一个设备代码(device_code)和一个用户代码(user_code),并返回一个验证URI(verification_uri)。
      • 用户使用辅助设备(如智能手机)访问验证URI,并输入用户代码以完成验证和授权过程。
    • 令牌获取:
      • 一旦用户通过辅助设备完成验证和授权,客户端设备可以通过轮询认证服务器的方式,使用设备代码获取访问令牌(access token)。
      • 轮询过程中,认证服务器会检查用户的授权状态,并在授权成功后返回访问令牌。
  • 安全性考虑

    • 由于Device Authorization Grant涉及用户在不同设备之间的交互,因此需要确保整个过程的安全性。
    • 认证服务器应使用HTTPS等安全协议来传输数据,并确保设备代码和用户代码的安全性。
    • 客户端设备在轮询认证服务器时,应遵循适当的频率和超时机制,以避免对认证服务器造成过大的负载。
  • 特点

    • 适用于输入受限设备:Device Authorization Grant特别适用于无法直接进行复杂用户交互或缺乏传统输入方式的设备。
    • 用户友好性:通过辅助设备进行验证和授权,提高了用户体验和便捷性。
    • 灵活性:该授权模式可以与OAuth 2.0的其他特性(如PKCE)结合使用,以进一步提高安全性。

Device Authorization Grant是OAuth 2.0中定义的一种授权模式,特别适用于无法直接进行用户交互或输入受限的设备。通过辅助设备进行验证和授权,提高了用户体验和安全性。在实际应用中,应根据具体场景和需求选择合适的授权模式,并确保整个流程的安全性和可靠性。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,753评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,668评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 166,090评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,010评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,054评论 6 395
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,806评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,484评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,380评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,873评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,021评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,158评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,838评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,499评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,044评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,159评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,449评论 3 374
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,136评论 2 356

推荐阅读更多精彩内容