mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-05 21:07:43 +00:00
GatewayJ
135 lines
4.3 KiB
Markdown
135 lines
4.3 KiB
Markdown
# OIDC Vendor Compatibility Checklist
|
|
|
|
Use this checklist when a vendor provides an OAuth or SSO document that is described as OIDC but does not clearly expose the standard OpenID Connect contract required by RustFS.
|
|
|
|
## 1. Discovery Metadata
|
|
|
|
RustFS expects provider metadata at:
|
|
|
|
```text
|
|
GET {issuer}/.well-known/openid-configuration
|
|
```
|
|
|
|
Ask the vendor to provide the discovery URL and confirm that it returns at least:
|
|
|
|
- `issuer`
|
|
- `authorization_endpoint`
|
|
- `token_endpoint`
|
|
- `jwks_uri`
|
|
- `response_types_supported`
|
|
- `subject_types_supported`
|
|
- `id_token_signing_alg_values_supported`
|
|
|
|
The returned `issuer` must exactly match the issuer configured in RustFS.
|
|
|
|
## 2. JWKS and Token Signature Verification
|
|
|
|
RustFS must verify the ID token signature. Ask the vendor to provide:
|
|
|
|
- `jwks_uri`
|
|
- supported signing algorithms, such as `RS256`
|
|
- key rotation behavior
|
|
- how the token `kid` maps to the JWKS key set
|
|
|
|
Without a verifiable ID token signature, the provider is not suitable for RustFS OIDC login.
|
|
|
|
## 3. Authorization Request Parameters
|
|
|
|
The provider must accept the standard authorization-code request parameters:
|
|
|
|
- `scope=openid profile email`
|
|
- `response_type=code`
|
|
- `client_id`
|
|
- `redirect_uri`
|
|
- `state`
|
|
- `nonce`
|
|
- `code_challenge`
|
|
- `code_challenge_method=S256`
|
|
|
|
If the vendor example omits `state`, `nonce`, or PKCE, confirm whether those parameters are supported.
|
|
|
|
## 4. Callback State
|
|
|
|
The provider must return the original `state` value in the callback:
|
|
|
|
```text
|
|
...?code=xxx&state=yyy
|
|
```
|
|
|
|
RustFS uses `state` for CSRF protection and to find the in-flight OIDC session. A callback that only returns `code` is not enough.
|
|
|
|
## 5. Token Response
|
|
|
|
The token endpoint response must be JSON and include at least:
|
|
|
|
- `access_token`
|
|
- `token_type`, usually `Bearer`
|
|
- `expires_in`
|
|
- `id_token`
|
|
|
|
RustFS requires `id_token`; an OAuth-only access token is not sufficient for Console OIDC login.
|
|
|
|
## 6. ID Token Claims
|
|
|
|
The ID token must contain standard claims that RustFS can verify:
|
|
|
|
- `iss`
|
|
- `sub`
|
|
- `aud`
|
|
- `exp`
|
|
- `iat`
|
|
- `nonce` when the authorization request includes `nonce`
|
|
|
|
Ask the vendor for a sample ID token payload and claim documentation.
|
|
|
|
## 7. UserInfo Endpoint
|
|
|
|
Standard OIDC UserInfo normally uses:
|
|
|
|
```text
|
|
GET /userinfo
|
|
Authorization: Bearer <access_token>
|
|
```
|
|
|
|
If the vendor only documents a private profile endpoint such as `/oidc/profile?access_token=...`, ask whether a standard `userinfo_endpoint` is available and returned in discovery.
|
|
|
|
## 8. Logout Endpoint
|
|
|
|
Standard RP-initiated logout is normally exposed through an `end_session_endpoint` in discovery. If the vendor only documents a private token removal endpoint, ask whether standard OIDC logout is available.
|
|
|
|
RustFS can still fall back to the Console login page when the provider does not advertise an end-session endpoint.
|
|
|
|
## 9. Authorization Claims
|
|
|
|
OIDC primarily authenticates the user. RustFS authorization is still based on RustFS policies. The provider must emit claims that can be mapped to RustFS policies, for example:
|
|
|
|
- `groups`
|
|
- `roles`
|
|
- `policy`
|
|
- another agreed flat array or string claim
|
|
|
|
Ask the vendor to confirm:
|
|
|
|
- whether group, role, or policy claims can be included in the ID token
|
|
- whether those claims can be included in UserInfo
|
|
- the exact claim names and value formats
|
|
- whether the claim values can match RustFS policy names such as `consoleAdmin`, `readwrite`, or `readonly`
|
|
|
|
If the provider only returns a user id or token validity result, it can authenticate the user but cannot by itself express RustFS authorization.
|
|
|
|
## 10. RustFS Redirect Requirements
|
|
|
|
RustFS browser-facing redirect behavior depends on these values:
|
|
|
|
- provider `redirect_uri`, when explicitly configured, is the callback URL sent to the provider
|
|
- `RUSTFS_BROWSER_REDIRECT_URL` is the public RustFS browser origin used for callback generation when no provider `redirect_uri` exists, and for Console success and logout fallback redirects
|
|
- dynamic request-header redirects are used only when no configured redirect source exists and dynamic redirects are enabled
|
|
|
|
Ask the vendor to register the exact callback URL, for example:
|
|
|
|
```text
|
|
https://rustfs.example.com/rustfs/admin/v3/oidc/callback/default
|
|
```
|
|
|
|
For load-balanced RustFS deployments, ensure authorize and callback requests reach the same RustFS node while the OIDC `state` is in flight.
|