Hi all, new here. I'm trying to set up a custom Auth0 SSO login for a customer's ORY Network IdP. Users should open our app (Auth0) and log in using the customer's IdP which is ORY Network. I think I have most of this set up correctly, but I'm struggling to pull back the user's details that are stored in

identities

after the OAuth2 dance. Where I'm at is that I have an ORY access token that looks like

ory_at...

and I think I want to hit

/sessions/whoami

(or maybe some admin endpoint?) but I don't know how to go from

ory_at...

to a session token (which it sounds like is a different thing?) Thanks! (also, I posted the same question in different words on SO: https://stackoverflow.com/questions/77411991/ory-network-get-identity-via-oauth2-flow)

Hi @many-parrot-95660 Just to clarify, how would the flow work and what are the constraints? From what I'm understanding you are using the Ory project as an OpenID connect provider and allow the user to do the OAuth dance from your service (the client) to Ory (the provider). Ory then returns to you with the access token in which you want to retrieve information regarding the user. Ory Network projects come with an OAuth 2.0 + OpenID connect (Hydra) and Idp service (Kratos). The Ory project in itself is already single sign on capable. So I guess the flow would look something like, the user is on your app (Auth0) and initiates an OAuth login flow by clicking "Sign in with X", in this case X is an Ory project. Ory then does the OAuth dance and returns to your app which exchanges the code for an access token. You can then call the userinfo endpoint with the access token to get whatever data the user consented to. Most of the data inside the access token would be dependent on which scopes you requested and which scopes the user consented to on the Consent UI. This can of course be implemented to always accept all scopes in a first party app integration. https://www.ory.sh/docs/oauth2-oidc/userinfo-oidc

Yeah that's right, but I think I want to be able to fetch data from the Kratos

/whoami

rather than the

userinfo

if possible. The specific usecase here involves figuring out if the user has a specific property which is incuded using identity schemas.

You don't need to access the

/whoami

- this also defeats the purpose of OAuth! (see here https://www.ory.sh/docs/hydra/concepts/before-oauth2) Kratos in any case sets a cookie scoped to the project domain - which means third party apps cannot just call

/whoami

. If your app is on the same domain as kratos then why do you need to do an OAuth dance in the first place? For the

userinfo

api, the access token can include all sorts of information. That's what the consent flow is for. In the case of Ory we by default add the traits associated with the `profile`scope (see here https://github.com/ory/kratos-selfservice-ui-node/blob/master/src/routes/consent.ts#L40C40-L40C40). You can of course have the project set additional data inside a custom consent route.

Also, the customer could customize the consent endpoint and return the data you need in the identity token payload.

Hmm interesting. I think this makes sense. To quickly answer • Different domains (we're a SaaS tool, their users are SSOing into us) • I dont think I'm mixing scopes and permissions, but maybe I'm wrong. Specifically the customer stores information like "professional license number" and "verification number" as part of the identity. The answer might just be that we need them to give us a different endpoint to access that data, I just figured that since its presumably accessible via the /whoami endpoint, I should use that. • I think potentially including the data in the

/userinfo

payload makes sense as well. We do that internally for places where we generate our own tokens (totally different user set and usecase). I think my mental model is SAML-ish if that helps explain my confusion. I'm also possibly confused about OAuth vs OCID? In my mental model, the user clicks the "Sign in with <ORY project>" and I end up with a OCID, which in my mental model is the same as what I'd expect in

identities

but I guess that's where I'm wrong?

If you ask for the

openid

scope, then it turns it in to OIDC, and you’ll get an id token along with the access token back. The id token payload is the same as what you’d get in the response to the /userinfo endpoint

Yeah, the goal is to avoid double data entry (and the user might not even know the relevant information (like their verification_id)). This was very helpful thanks!