ORY Hydra and validating an OpenID Connect login

1.6k views Asked by At

Does ORY Hydra currently have a feature that verifies if a client is logged in via OpenID Connect? I notice there is an API to logout via front-channel

When a user revisits the identity provider, however, I have no way of knowing if they are currently logged in or not. They could delete their client-side HTTP cookies and then I am out of sync with Hydra. Meaning: Hydra has them as logged in, but I have them now as logged out. Also, in the event of a back-channel logout, I want to be able to query for this state.

Is there an API I am overlooking that allows me to know whether a client currently has an active OpenID Connect login via Hydra?

It appears as of right now the only thing one can do is redirect the user to the authorization endpoint since we have no way of knowing if they are authorized or not.

The following two tables that ship with Hydra seem to be the source of truth for the data I am after: hydra_oauth2_access and hydra_oauth2_authentication_session. Does it ever make sense to query those directly if there is no supported HTTP API out of the box to see if a user has an active authentication session?

2

There are 2 answers

1
Hans Z. On BEST ANSWER

Sending an authentication request via a redirect to the Provider including prompt=none addresses this use case: it will silently login and return new tokens if there's an ongoing SSO session at the Provider, it will return an error code login_required if not.

Notice there will never be explicit user interaction in both cases so this is convenient (and meant) to run in an hidden iframe.

0
Gary Archer On

LOGGED IN STATE

An OAuth client is most commonly a UI application with multiple users. Each user's logged in state is represented by an Authorization Server session cookie that neither the application or user have access to:

  • The Authorization Server (AS) issues an SSO cookie, to be stored in the system browser for the AS domain
  • Both Web UIs and Native UIs send it implicitly on subsequent requests, when they invoke the system browser

AUTHORIZATION REDIRECTS

When an OAuth UI redirects the user, it is generally unknown whether:

  • The user will be prompted to login
  • The user will be signed in silently (eg the user could have signed in to another app)

For a Web UI it is possible to send an authorization redirect on a hidden iframe with a prompt=none parameter. If the user needs to sign in a login_required error code will be returned. See my Silent Token Renewal Page for further details.

This is not fully reliable however, and has some browser issues in 2020. Also it may be unsuitable if you are using a different type of client.

FEDERATED LOGINS

In some setups the AS redirects further to an Identity Provider (IDP), and the user's login state is further influenced by an IDP session cookie.

There is no way for an app to get hold of the user's IDP login state, since the app only ever interacts with the AS.

IS THERE A USABILITY PROBLEM?

If so, post back and we can discuss further ...