Home > Net >  Why does the Oauth technique differ for a web browser (traditional web app, not SPA) based app and a
Why does the Oauth technique differ for a web browser (traditional web app, not SPA) based app and a

Time:02-15

I'm reading about Oauth and understand that for a browser based web app (traditional web app, not SPA), when browser clicks on button to login, then the web server code can be configured to integrate with an Oauth provider that redirects user to the Oauth provider login page and so on.. eventually the web server receives the token from the Oauth provider. This token can be passed by the web server to the resource server for authorized access.

Where as if the end user is using a native mobile app, then the integration must be done from the app to the Oauth provider directly, preferably via pkce. The mobile app receives the token and then the token can be passed into the resource server api for authorized access to the resource.

I'm just curious to know why the technique differs for a web browser based app and a native mobile app?

And whether there is a way by which I can use the technique from the 1st paragraph for a native mobile app and technique from 2nd paragraph for a browser based app?

CodePudding user response:

The main difference between the two lies in the fact that a web app can have "secrets" and a native app can't.

That means that in case of a web app a client_secret which is essential to the "main" OAuth flow can be stored somewhere in a backend configuration securely, while the native app can't have one: all of the application code is being downloaded and therefore must contain the above mentioned client_secret which can be extracted from an .apk file. Notice that this problem is prevalent in SPA style web apps.

PKCE provides a possibility for clients to generate client_secrets during runtime, which ensures their integrity.

As to whether or not you can use PKCE in a main (authorization grant) flow, you absolutely can.

  • Related