CODEWITHSUNDEEP
oauth-2.0openid-connectpkcemobile-security
glcohen
glcohen

Reputation: 193

Risks in shortcutting OAuth/OIDC?

I'm building an OIDC/OAuth server that will provide an SDK much like sign in with Google to be an IDP for mobile apps. We are wondering the risks of deviating from the protocol to simplify the flow.

The flow would be like this:

  1. OIDC Server is setup for company A.
  2. User opens app from company B, using company A OIDC SDK, and enters email
  3. Pin challenge sent to email
  4. Pin entered in app, screen shows consent prompt
  5. On ok, app gets ID + Auth token for user

The token accessible to the app is only scoped to a limited set of resources accessible to the app and can be revoked by the user at any time.

This cuts out a few steps from the normal PKCE+Auth code flow, and I’m having a hard time articulating why this may be worse for security (besides not following a widely accepted standard).

Upvotes: 0

Views: 130

Answers (2)

Hans Z.
Hans Z.

Reputation: 53928

There is a standardised OAuth 2.0 extension that somewhat resembles your approach, defined in RFC 8628 https://datatracker.ietf.org/doc/html/rfc8628 "OAuth 2.0 Device Authorization Grant".

A few remarks about your flow:

  • it seems to imply that the ability to read e-mail equals user authentication i.e. the e-mail provider is the authentication provider; that may not be applicable in general
  • the spec warns that this approach should not be used to replace vanilla browser-based SSO on mobile devices that do have a browser mostly because of loss of flexibility and it results in a more cumbersome user experience
  • I don't think there are immediate or more security concern than the ones mentioned in RFC 8628 (https://datatracker.ietf.org/doc/html/rfc8628#section-5), but as mentioned before, you'd be on your own to find support in SDKs, apps and OPs when not following the standard

Upvotes: 0

Michal Trojanowski
Michal Trojanowski

Reputation: 12322

Standards around security are created so that common attack vectors can be more easily mitigated. If you don't follow the standard you will have to make sure yourself that you're meeting security requirements of your product/company.

It's hard to tell from that simple description whether your app will be vulnerable or not. E.g. in point 4 - how do you make sure that the app which sends the OK to consent is the one which asked for the consent in the first place? How do you make sure that the auth token is delivered to the appropriate app? What will be the TTL of such a token? How will you refresh it? What is your plan for a situation when the token gets stolen or intercepted, etc. These are all things which you will have covered if you follow OIDC or OAuth standards and their security recommendations. When you start inventing new ways to guard yourself from those threats, you might end up creating something similar to the standards anyway.

Also, if you implement standard flows, it will be easier for you to change your own OAuth Server to a product available on the market, should that become a necesity.

Upvotes: 1

Related Questions