Reputation: 315
I'm working on a product with two apps: one a single-page web app, and the other a native mobile app. Both make use of the same backend API. Currently the user authenticates using username/password credentials to establish a session cookie. I'm planning on adding support for authentication using OpenID Connect.
For the web app, I'm looking at following the advice for "JavaScript Applications with a Backend" in "OAuth 2.0 for Browser-Based Apps". In that scenario, the authorization code gets sent to the backend, which obtains the ID token and begins a cookie-based session.
I'm trying to work out how this would work on Mobile. The "go to" implementation of OAuth/OIDC on mobile appears to be AppAuth. From what I can see, AppAuth uses a different approach where you end up doing the auth code exchange on the device to get the ID token.
Should I have the mobile app send the ID token on to the backend to prove the user identity (and then begin the session)? Is there any best practice around doing this? Presumably at least the backend would need to validate the JWT and verify the signature?
Alternatively, can AppAuth be used to do a similar flow as done on the web app as mentioned above?
Upvotes: 2
Views: 1433
Reputation: 29208
The mobile case does indeed work differently, and is defined in RFC8252, which defines the AppAuth pattern. Both the web and mobile cases have this in common:
Cookies are not used in mobile views, and mobile apps can store tokens securely, unlike browser based apps. The mobile app will send access tokens to APIs, and also make token refresh requests when needed.
Out of interest there are easy to run versions of each in my online code samples, if you want something to compare against. Both flows are tricky to implement though.
Upvotes: 1