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:

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:

...?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:

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:

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.