Bridging Authentication Across Systems
Explore how to connect systems that use different authentication schemes, from delegated user access to workload credentials. Learn how to decide whose authority each connection carries and how tokens are scoped, renewed, rotated, and revoked. Understand how to enforce access per user, field, and tenant even when data is cached or copied.
We'll cover the following...
- Why Rill’s API rejects a signed-in user
- Connections that act for a person and connections that act for Rill
- When a case token is usable and how it is renewed
- Which OAuth controls protect against which attacks
- Reaching warranty W42 for u17 without sharing signing secrets
- Why the importer can read C99 while u17 cannot
- Rotating v1 and recovering from revocation
A staff member signs in successfully to Rill Parts’ portal, opens a case, and receives an API access-denied response. Successful login established a portal identity; the case API still needs an authorized caller and a credential it accepts. Bridging authentication means specifying that access contract for each connection while keeping a user’s permissions intact across adapters and copied data.
Why Rill’s API rejects a signed-in user
Suppose Rill’s portal uses SAML single sign-on and SCIM provisioning. Its case API supports delegated and application OAuth access, its warranty API requires OAuth 1.0a, and its supplier API requires an API key plus a client certificate.
Distinguish four concepts:
Authentication: Establishes an identity by answering “Who signed in?”
Federation: Establishes trust in another identity provider’s assertions by answering “Whose identity evidence does the portal accept?”
Provisioning: Creates, updates, or disables accounts and group memberships, answering “Does this account exist and remain active?”
Authorization: Decides which resources and actions an identity may access, answering “May this caller read this case?”
SAML commonly supports federated login. OIDC adds an identity layer to OAuth 2.0; OAuth governs access to protected resources; SCIM supports provisioning. None alone guarantees downstream business permissions.
Rill’s SAML login creates a portal session, not a case-API access token. SCIM group membership supplies policy input; the API still enforces its authorization model. Identify both the human caller and the integration identity used at each downstream boundary.
Connections that act for a person and connections that act for Rill
Delegated access acts with a user’s authorization. Workload access acts as an application or service identity. A service account is an identity, not a universal credential format or an OAuth grant.
Under Rill’s assumed provider capabilities, choose this compact connection inventory:
Case viewer: The signed-in user authorizes user-scoped access to the case API through authorization code with PKCE. Request ...