Would you use OAuth for your own applications? If so, how do you handle the consent screen?

[Mads Mobæk]

Given the following scenario:

[ My app ]     [ Third party]

         |             /

[         API Gateway         ]

          |               |

[ API app 1 ] [API app 2]

What kind of security would you apply for your own app and third parties? I currently consider using OpenID Connect + OAuth 2 and putting a proxy/API gateway in front of the apps to do authorization. This works well for third party cases, but has some quirks when it comes to my own web app. It seems strange to present "My app requests the following permissions: ..." (since its a trusted client, after all). Similarly, you don't see the official facebook/twitter/<insert app here> ask for this. 

I haven't found any specifics in the specs about it, other than:

5.2.3.2.  Require User Consent for Public Clients without Secret

   Authorization servers should not allow automatic authorization for
   public clients.  The authorization server may issue an individual
   client id but should require that all authorizations are approved by
   the end user.  For clients without secrets, this is a countermeasure
   against the following threat:

   o  Impersonation of public client applications.

My interpretation is that public clients (implicit flow / native apps) should show a consent screen, but a server-side authorization grant flow may whitelist clients for skipping the user consent? If that's the case, then a OIDC / OAuth provider must implement this feature or I would have to do a custom implementation.

A alternative would be to use something else than OIDC / OAuth for my own apps, regular sessions for instance. This would require "my app" to produce a valid session after login (in its own login flow), and have the API gateway accept either a OAuth access token (coming from third parties) or a session cookie (coming from my own app). 

I'm wondering how you would solve this? How have others solved it?

[Jørn Wildt]

I think this goes back to a classic problem for applications that cannot truly protect secrets - like for instance mobile apps (as opposed to web applications where the server is able to protect OAuth client credentials). There is no way for the mobile app to prove that it is in fact your application - any means of hiding client credentials in the app can be reverse engineered by hackers.

Having said that, I would assume you could use the client ID to change server behavior - if it is the client ID of your app then the login process can be simplified.

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Owen Rubel]

Actually thats not true. Mobile apps can be given their own unique token each time they register or are purchased

[Jørn Wildt]

How does that change the fact that someone can by an authorized app, reverse engineere the generated code and use it in their own third party app to avoid user content?

/Jørn

--
/Jørn

[Owen Rubel]

Would also have to match a generated app_id and potentially a manufacturer_id as well as generation mac address. All you did happen to do all that, all you would have is an app with the same limitations that only worked locally on your device. No big deal.

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

--
/Jørn