4

I am having difficulty understanding Hybrid flow with mobile application. I am using code id_token Hybrid flow provided by Identity Server 4 in .Net.

Here is my scenario. enter image description here

All mobile request will go to backend server and backend server will forward request to different APIs on user behalf.

When user first time login

  1. He will be redirected to identity server
  2. A mobile web view will be opened
  3. User will sign in using credentials
  4. identity server will send Id Token and Access Code to Back end Server
  5. Back end Server will swap Access code for Id Token and Access Token

What token will be returned to mobile application to provide that user is valid. And is it responsibility of Back end server to get new access token without prompting user to re login until user sign out?

Is there any step wrong in above scenario ?

Epistemologist
  • 1,052
  • 3
  • 15
  • 34

1 Answers1

3

For mobile clients its recommended to use Authorisation code flow along with PKCE. Please read through these two answers to grasp some idea why its suggested Link-1 & Link-2.

Also, RFC8252 provide some best practices application for Native Apps (mobile clients are native apps.!). In that, it recommend not to use web-views.

here is a quote from RFC8252-overview

Previously, it was common for native apps to use embedded user-agents (commonly implemented with web-views) for OAuth authorization requests. That approach has many drawbacks, including the host app being able to copy user credentials and cookies as well as the user needing to authenticate from scratch in each app

By using web-view, you loose the true essence of OAuth 2.0. You client app get the ability to grasp end user credentials. So use the browser instead of web-view. (Please read more about embedded users agents from this link)

In your architecture, you could enable all of these, PKCE, Authorization code flow and usage of browser instead of web-view. But once the backed receives tokens, it should pass them to your client. That will be a challenge if you stick to this architecture.

But if you can make your mobile application to complete whole flow, you avoid that complexity. Once tokens are received, you may create a connection between backed server by validating tokens. Also, when tokens expire, mobile app will use refresh token to obtain new tokens.

Community
  • 1
  • 1
Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46
  • "But once the backed receives tokens, it should pass them to your client. That will be a challenge if you stick to this architecture." Can you please elaborate. – Epistemologist Feb 23 '18 at 07:14
  • @Epistemologist How can server push tokens back to your client ? Will there be open sockets ? Or any other push mechanism ? That would be a complex situation. I would rather make my mobile app to handle the flow and obtain tokens. – Kavindu Dodanduwa Feb 23 '18 at 08:54
  • 1
    I agree that hybrid or auth code flow with PKCE and using system browser or OS provided broker is the best approach. Regarding receiving the response... It's not really a challenge, it's a well trodden path and it's possible to use custom URL schemes or local HTTP listeners to receive to the authorize endpoint response in a native app. @Epistemologist The bit that's not correct in you diagram is that the mobile app/device will be communicating directly with the identity service and the access token will be held on the device. – mackie Feb 23 '18 at 10:10
  • @mackie Lets say mobile device will communicate directly with IdentityServer and receive Access Token but than I have to save client secret on mobile application which is insecure. Is there any workaround to this problem ? – Epistemologist Feb 23 '18 at 12:28
  • If mobile application is communicating directly with identity server than what does it mean that Authorization code is transmitted by front end channel like browser and Access token is received by back end channel. Am I perceiving back end channel wrong ? – Epistemologist Feb 23 '18 at 12:57
  • @Epistemologist Mobile clients are considered public clients so you should assume that the client ID is public and not use it to protect any sensitive scopes for example. This explains more: http://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applications-with-pkse/ – mackie Feb 23 '18 at 15:10
  • @mackie yes, receiving is pretty straightforward if protocol is run only by mobile application. But if he use the architecture shown in his diagram, it will be difficult. Front channel is using browser. back channel will be direct communication with token endpoint. Hope it's clear now – Kavindu Dodanduwa Feb 24 '18 at 10:29
  • What is the correct way to implement registration of a new user in this scenario? https://stackoverflow.com/questions/60187173/oidc-register-auto-login-flow-for-mobile-apps @KavinduDodanduwa – Yashvit Feb 13 '20 at 05:41