Hello Ory 👋 I wanted to share an approach that we are currently planning, and also for us get some feedback if we doing it correctly 😉 We want to provide a smooth mobile social sign-in experience, that leverages native flows, creates users in Kratos and provides in the end Hydra oauth2 tokens to the application. Premises: • Our mobile app has already an oauth2 client configured in Hydra. • In the social provider, we configured two oauth2 clients, one for the client-side mobile app, and one for Kratos (which will be used for the Web browser-based social sign-in). The flow would go like this: 1. The mobile app uses the social providers SDK and performs the social sign-in using it. 2. Once it's finished and we received the OIDC

id_token

, we send it to our internal authentication service 3. This service will start an API Kratos flow, and then submit the

id_token

to Kratos (using https://github.com/ory/kratos/pull/2346 once is ready) 4. Kratos identifies the user or creates it, and returns a session token, which our service returns to the mobile app. Now the mobile app has a Kratos session token, but our apps require Hydra oauth2 tokens to authenticate. So then: 1. The mobile app starts the Hydra oauth2 using its client ID in an in-app browser (and we attach the Kratos session token) 2. It gets redirected to our login form, with the Kratos session token as query param. 3. Our service checks the Kratos session token validity, and accepts the login. 4. Hydra redirects to the redirect URI with the auth code. The issues we see is that: • The Hydra flow will require to open an in-app browser on mobile, which opens and closes without user interactions, which is less than ideal. Is there any alternative? • I'm unsure that a web social sign-in flow (with Kratos) using the same social provider as on mobile, would actually connect the same user or create a new one. If the same social provider has 2 different clients, will they be represented by 2 different credentials identifiers in Kratos, or will they be the same? Any thoughts about this? 🙂 Thanks a lot for your awesome work and for your help 💪 🙇

The Hydra flow will require to open an in-app browser on mobile, which opens and closes without user interactions, which is less than ideal. Is there any alternative?

IMO the best alternative would be to just use the Kratos flows and forgo the Hydra OAuth2 tokens - then there is no browser needed on mobile. I dont think there is a good alternative, a lot of work was done in Kratos to make this smooth flow possible. Can you share a bit of background why you need OAuth2 tokens, maybe I am missing something? I don’t have too much experience with mobile clients, forgive me 🙏

I’m unsure that a web social sign-in flow (with Kratos) using the same social provider as on mobile, would actually connect the same user or create a new one. If the same social provider has 2 different clients, will they be represented by 2 different credentials identifiers in Kratos, or will they be the same?

When using the login flow for browsers or API clients this will both be the same identity in Kratos (once the aforementioned support for OIDC in API-based flows is implemented).

Hey Vincent! Thanks a lot for your answer.

Can you share a bit of background why you need OAuth2 tokens

We are planning to pass some information in the OAuth2 tokens, we will need them. The Kratos token is too opaque for our usage here.

When using the login flow for browsers or API clients this will both be the same identity in Kratos (once the aforementioned support for OIDC in API-based flows is implemented).

Thanks for the clarification! That helps me 🙏 There is a fair chance we won't go with a native mobile experience in our MVP, and stay browser-based to avoid these complexities for now. Maybe I'll circle back in a few months to ask more questions or give some feedback 😉

We are planning to pass some information in the OAuth2 tokens, we will need them. The Kratos token is too opaque for our usage here.

What do you mean by opaque? You can use Metadata for data that should not be visible to the end-user, although its best practice to keep your business logic related data close to where you need it (i.e. in your application rather than the identity service). The cookie is protected by highest standards • `secure`: The cookie is only sent over HTTPS connection to protect against man-in-the-middle attacks. • `httpOnly`: The cookie is not available to JavaScript code to protect against XSS. • `sameSite=Strict`: The cookie can only be requested from the same origin to protect against CSRF attacks.

Indeed, but we aim to store information in the token itself 🙂

Yes, that is also possible using for example Ory Oathkeeper https://www.ory.sh/docs/oathkeeper/ to mutate the cookie into a JWT.