OAuth 2.0
Casdoor会颁发访问令牌以对客户端进行身份验证。 本页面介绍如何通过API获取令牌、验证令牌并使用它。 或者,使用Casdoor SDK来 处理该流程。
支持的授权类型:
| 授权类型 | RFC | 用例 |
|---|---|---|
| 授权码 | RFC 6749 §4.1 | 默认;带有后端的Web/移动应用。 默认启用。 |
| t隐式 | RFC 6749 §4.2 | 仅前端应用,无后端。 |
| 资源所有者密码 | RFC 6749 §4.3 | 无前端重定向的应用程序;用户凭据直接发送。 |
| 客户端凭证 | RFC 6749 §4.4 | 服务间调用,无需用户参与。 |
| 刷新令牌 | RFC 6749 §6 | 无需重新认证即可续订访问令牌。 |
| 设备授权 | RFC 8628 | 输入受限或无浏览器的设备 |
| 令牌交换 | RFC 8693 | 用现有令牌交换具有不同范围或受众的令牌。 |
| JWT持有者 | RFC 7523 | 使用签名的JWT断言而非客户端密钥进行服务身份验证。 |
在应用程序编辑页面上启用非默认授权类型。

Authorization code grant
将用户重定向至:
https://<CASDOOR_HOST>/login/oauth/authorize?
client_id=CLIENT_ID&
redirect_uri=REDIRECT_URI&
response_type=code&
scope=openid&
state=STATE
作用域
| 作用域 | 描述 |
|---|---|
| openid(默认) | sub, iss, aud |
| profile | name、displayName、avatar |
| 电子邮件地址 | |
| address | 地址(OIDC 对象在JWT 标准中;请参阅OIDC 地址声明) |
| phone | 电话号码 |
:::信息 授权 URL 中的请求范围 用``%20:
https://<CASDOOR_HOST>/login/oauth/authorize?
client_id=...&
scope=openid%20email
请参阅OIDC 规范以了解详情。 :::
用户登录后,Casdoor 将重定向至:
https://REDIRECT_URI?code=CODE&state=STATE
使用 POST 将代码兑换为令牌:
https://<CASDOOR_HOST>/api/login/oauth/access_token
请求体:
{
"grant_type": "authorization_code",
"client_id": ClientId,
"client_secret": ClientSecret,
"code": Code,
}
示例响应:
{
"access_token": "eyJhb...",
"id_token": "eyJhb...",
"refresh_token": "eyJhb...",
"token_type": "Bearer",
"expires_in": 10080,
"scope": "openid"
}
Casdoor支持PKCE(代码交换证明密钥),以增强安全性。 要启用PKCE,请在请求授权码时添加两个参数:
&code_challenge_method=S256&code_challenge=YOUR_CHALLENGE
代码挑战应为随机生成的代码验证器的Base64-URL编码SHA-256哈希值(长度为43至128个字符)。 请求令牌时,请包含原始code_verifier参数。 启用 PKCE 后,``client_secret变为可选,但如果提供,则必须正确。
对于在Casdoor中配置的OAuth提供商(如Twitter以及启用了PKCE的自定义提供商),Casdoor会为每个认证流程自动生成唯一的代码验证器,因此您无需手动实现PKCE。
将令牌绑定到特定服务
当您的应用程序需要调用多个后端服务时,您可能希望使用明确绑定到特定服务的令牌。 这可防止出现安全问题,即本应用于某项服务的令牌意外地被用于另一项服 务。
Casdoor 支持 RFC 8707 资源指示符,允许您在请求授权时指定预期的服务。 添加``资源参数,其中包含用于标识您的服务的绝对URI:
https://<CASDOOR_HOST>/login/oauth/authorize?
client_id=CLIENT_ID&
redirect_uri=REDIRECT_URI&
response_type=code&
scope=openid&
state=STATE&
resource=https://api.example.com
When you exchange the authorization code for tokens, include the same resource parameter:
{
"grant_type": "authorization_code",
"client_id": ClientId,
"client_secret": ClientSecret,
"code": Code,
"resource": "https://api.example.com"
}
生成的访问令牌将把aud(受众)声明设置为您的资源 URI,而非客户端 ID。 您的后端服务随后 可以通过检查受众声明来验证令牌是否专门为其颁发。 资源必须在授权请求和令牌请求之间完全匹配。
资源参数在基于浏览器的登录流程中得以保留。 如果用户需要完成交互式登录(例如输入密码、MFA 或 WebAuthn),该参数将贯穿整个重定向链,并在颁发授权码时一并包含。
provider_hint参数
要跳过Casdoor登录页面,直接将用户发送到特定的OAuth提供商,请在授权URL中添加provider_hint=<provider-name>:
https://<CASDOOR_HOST>/login/oauth/authorize?
client_id=CLIENT_ID&
redirect_uri=REDIRECT_URI&
response_type=code&
scope=openid&
state=STATE&
provider_hint=github
Casdoor 提供一个轻量级的重定向页面(无需加载完整的 React 应用),可立即将用户引导至该提供商的 OAuth 流程。 这可缩短在设备资源受限或网络连接较慢时的重定向时间。
带有 OAuth 的注册流程
当用户通过 OAuth 授权流程注册时,他们会自动被重定向到您的应用程序的回调 URL,并附带授权代码,这与登录流程完全相同。 此前,用户在创建账户后必须手动点击进入中间页面。 现在,注册流程与登录的简化体验保持一致——注册完成后,Casdoor会立即生成授权码并重定向到您的``redirect_uri.
<b您的应用程序无需任何更改即可支持此功能。 在 OAuth 授权过程中,当用户选择创建新账户时,授权参数(client_id、response_type、redirect_uri 等)会自动通过注册流程传递。
隐式授权
对于没有后端的应用程序,请使用隐式授权. 在应用程序中启用它,然后将用户重定向到:
:::警告
隐式授权令牌端点需要有效的用户名和密码。 纯 OAuth 用户(仅通过第三方提供商创建的账户,未设置本地密码)无法使用此流程,并将收到``invalid_grant. 对社交登录用户使用授权码流程。
:::
https://<CASDOOR_HOST>/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=token&scope=openid&state=STATE
当您的用户通过 Casdoor 身份验证后,他会被 Casdoor 重定到:
https://REDIRECT_URI/#access_token=ACCESS_TOKEN
Casdoor也支持id_token作为response_type,这是OpenID的一个特性。
设备授权
对于输入受限或无浏览器的设备,请使用设备授权. 在应用程序中启用它,请求来自OIDC发现的device_authorization_endpoint,然后显示verification_uri(例如通过二维码或文本),以便用户完成登录。
Casdoor provides a built-in device login page at the verification_uri where the user enters the user code and signs in — no custom UI is required. Device login can also be enabled as a sign-in method on the application's Signin methods table.
其次,您应请求令牌端点以获取访问令牌,并使用rfc8628中定义的参数。
The pending device-authorization requests (the mapping between the device code and the user code) are held in an in-memory store by default. In a multi-replica / horizontally-scaled deployment, the polling request from the device and the browser confirmation may land on different replicas, so an in-memory store causes the device flow to fail intermittently.
To make the device flow work across replicas, configure redisEndpoint in conf/app.conf. When it is set, Casdoor automatically backs the device-authorization store with Redis so all replicas share the same state. No extra configuration key is needed — the same redisEndpoint value used for shared sessions is reused (format: host:port[,db[,password]]). If Redis cannot be reached at startup, Casdoor logs a warning and falls back to the in-memory store. See Configuration.
使用资源拥有者的密码凭据授权
如果您的应用程序没有前端来重定向用户到Casdoor,那么您可能需要这个功能。
在应用程序上启用密码凭据授权,然后向以下地址发送 POST 请求:
https://<CASDOOR_HOST>/api/login/oauth/access_token
{
"grant_type": "password",
"client_id": ClientId,
"client_secret": ClientSecret,
"username": Username,
"password": Password,
}
示例响应:
{
"access_token": "eyJhb...",
"id_token": "eyJhb...",
"refresh_token": "eyJhb...",
"token_type": "Bearer",
"expires_in": 10080,
"scope": "openid"
}