OpenID Connect
The modern successor to SAML, and the mechanism most new applications use to establish who someone is. Same purpose, lighter machinery, better suited to mobile and browser experiences.
The modern successor to SAML, and the mechanism most new applications use to establish who someone is. Same purpose, lighter machinery, better suited to mobile and browser experiences.
What OpenID Connect holds, and why that matters here
OpenID Connect layers identity on top of a widely used authorisation framework. It is what most contemporary applications use for sign-in, and it is particularly well suited to browser and mobile contexts — which is where an assistant usually lives.
The practical effect for an assistant is identical to SAML: the person is identified by the organisation's own identity provider, and the assistant answers within whatever that identity is entitled to.
- Identity tokens — the signed statement of who the user is.
- Claims — attributes describing the user and their entitlements.
- Scopes — what the application is permitted to know about them.
- Sessions — sign-in state across applications.
- Refresh — maintaining a session without repeated sign-in.
Questions OpenID Connect lets Elbi answer
Who is this person?
Established from a signed token issued by your identity provider.
What are they entitled to?
Claims that determine what the assistant may disclose.
Is the session valid?
Session state, so an expired session does not answer personal questions.
What is their role?
Claims used for entitlement and routing.
Which tenant or entity?
Where a group operates several, the claim determines which data applies.
Has anything changed?
Claims reflect the current position rather than a cached one.
How Elbi uses OpenID Connect
- Elbi becomes a client of your providerYour identity team registers Elbi as a client in the provider you already run, records the exact redirect address it uses, and issues its client credential. Commercial and open-source providers implement OpenID Connect in much the same way, so the steps look familiar whichever one you use.
- Sign-in by authorisation codeThe person is sent to your provider's sign-in page, signs in there under your policies, and returns with a one-time code that is exchanged for tokens. Current guidance pairs this flow with PKCE for browser and mobile clients and discourages the older implicit flow.
- The ID token is verified, not taken on trustThe token is signed by your provider. The specification requires the receiving application to check that signature against the provider's published keys, and to check the issuer, audience, expiry and nonce, before believing anything the token says.
- Scopes limit what is sharedThe openid scope identifies the person; profile and email add basic attributes. Roles and groups are usually a provider-specific claim you add on purpose, and Elbi should receive only the claims its rules actually use.
- The subject claim is the keyThe identifier to rely on is the provider's subject claim, not the email address. Email addresses change and are sometimes reassigned; the subject is meant to stay with one account for its whole life.
- Sessions are set by the providerHow long a sign-in lasts, and whether it can be refreshed without signing in again, is configured in your provider. Shorter sessions mean a revoked account stops working sooner.
Scope and control over an OpenID Connect client
| Direction of access | One-way. Your provider asserts who someone is; Elbi reads the assertion and never creates, edits or manages accounts in the provider. |
|---|---|
| Who can see what | Entitlement follows the claims in the token, which your provider controls. Most providers can also restrict which users or groups may use a given client, so a person can be refused before any token is issued. |
| Credentials | The client credential is issued by your provider and stays under your control. Rotate it on your own schedule; disable the client and every sign-in to Elbi stops at your provider. |
| Where data goes | Claims decide what Elbi may answer within that conversation. Message content is destroyed within 24 hours, and usually sooner when the conversation ends; no external AI service receives it. |
| Audit | Your provider's logs record each sign-in to the client. Elbi can record which verified identity each lookup ran under, so the two trails line up. |
| If the provider is down | New sign-ins cannot happen, so Elbi carries on with answers that need no identity. It does not accept an expired token as a substitute. |
What this replaces
The advantage over older federation in an assistant context is fit. Assistants live in browsers and mobile applications, and OpenID Connect was designed for exactly those contexts — which makes the sign-in experience cleaner and the session handling more predictable.
The security position is the same and is the important part: identity is established outside the conversation by a system the organisation controls. Nothing a user types can change who the assistant believes they are.
Scopes add a useful refinement. The assistant can be granted only the claims it actually needs rather than everything the identity provider knows, which keeps the connection narrow in the same way a scoped system connection does.
Where OpenID Connect fits best
Customer-facing portals
Where customers already sign in to an account.
Mobile applications
Sign-in designed for the context the assistant lives in.
Modern enterprise estates
The default for contemporary applications.
Multi-tenant groups
Claims determining which entity a user belongs to.
Getting value from OpenID Connect
OpenID Connect pays off where people are already signed in somewhere. If staff reach Elbi from an intranet that uses your provider, or customers from a portal or mobile app with an account, the assistant can recognise them without a second login — and the first question worth connecting is the one they currently leave that page to ask.
For customer channels that usually means the account-specific questions: the status of an application, an order, a booking or a claim. They are exactly the questions an anonymous chatbot has to refuse or send to a call centre, and they are where identity turns a general assistant into a useful one.
The discipline is in the claims. It is tempting to ask the provider for everything it knows about a person. A narrow claim set — subject, name, and one role or customer reference — covers most first deployments and is far easier to defend when someone asks what the assistant is told about each user.
What connecting an OpenID Connect provider involves
- Start from the discovery documentEvery compliant provider publishes a discovery document listing its endpoints and signing keys. Configuration starts from that document rather than from addresses copied by hand.
- Create a confidential clientRegister Elbi with its exact redirect address, the authorisation code grant and a client credential your team issues. Wildcard redirect addresses should not be accepted.
- Agree the claim setDecide which claims Elbi receives — typically subject, name and a role, group or customer reference — and configure the provider to include them. Group and role claims are not standardised, so their name and format are agreed for your provider.
- Set session and token lifetimesChoose how long a sign-in lasts before the person is asked again, with particular care for customer channels used on shared or mobile devices.
- Map claims to answersWrite down which claim values unlock which topics, and what the assistant says when a claim is missing. That mapping is the document your security review will read.
- Test the edgesAn expired session, a user with no role claim, a token minted for a different client, a changed email address. Each should fail safely and explain itself in plain language.
Claims, consent and the PDPL
Every claim in an ID token is personal data about the person signing in. The standard claims can carry name, email address, phone number, date of birth and postal address; under the Personal Data Protection Law the question is not what the provider can send but what the assistant needs.
Where your provider shows users a consent screen, it lists what the application is asking for, so a short list is also a clearer notice. Requesting address or phone number in case they prove useful makes that notice longer and the purpose harder to state.
Tokens are sensitive in their own right. An access token in the wrong hands can act as the person until it expires, and an ID token discloses who they are. Neither belongs in URLs, analytics or support logs, and short lifetimes are worth their small inconvenience.
What organisations typically see
How other chat tools establish identity
Many customer-messaging tools identify signed-in visitors by having the host website pass them a signed value — a hash or token the site generates for its own users. It works, but each vendor defines its own scheme, and your team implements and reviews it separately for each tool.
Others fall back on asking: an account number, a date of birth, the last digits of a card. Knowledge-based checks are familiar, but the answers are often guessable or already exposed, and they teach customers to type personal details into a chat window.
OpenID Connect replaces both with a standard your identity team already operates and your security team already knows how to review. The assistant becomes one more client of the provider, subject to the same policies, logs and revocation as every other application you run.
Common questions
Different rather than better — it fits browser and mobile contexts more naturally, which is usually where an assistant runs.
Yes, through scopes. The assistant should receive only the claims it needs.
It is a standard, configured during deployment.
No. People sign in on your provider's page, and Elbi receives a signed token describing the result — never the password or the second factor.
Usually through separate clients, often in separate providers. Workforce and customer identity carry different policies, and keeping them apart keeps each review simple.
Personal answers stop until the person signs in again. General questions carry on, and the assistant says plainly why it is asking them to sign in.
Sign people in once, with the provider you already run
Elbi as one more OpenID Connect client, answering in Arabic and English within the claims you choose to share.