0

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).

glcohen
  • 193
  • 1
  • 1
  • 11

2 Answers2

1

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.

Michal Trojanowski
  • 10,641
  • 2
  • 22
  • 41
  • Thank you, this is great feedback. I will bring these points back to the team and make sure we address them. – glcohen Jul 20 '21 at 17:47
  • One question, Michal -- why is it important to log in with the IDP? What if the IDP sent a pin that enabled delegated auth to an email. The pin is redeemed in the 3rd party app, which uses a PKCE-like mechanism. What security is lost by not having a session on the IDP? – glcohen Jul 22 '21 at 00:28
  • Having a session at the IDP is not a requirement. It's totally up to your implementation how will you authenticate the user. Sending a pin to the user email is as valid authentication option, as e.g. providing a username and password. – Michal Trojanowski Jul 22 '21 at 20:16
  • Yeah, that makes sense. I mean, what is the risk of doing the sign in through the 3rd party as opposed to with the IDP. If I do a pin challenge with the 3rd party, then the result is getting an access token. It does by pass the consent step, which could be surfaced in the email for challenge... – glcohen Jul 27 '21 at 18:51
0

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
Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • This makes sense. I will look into 8628. The biggest loss seems to be not being able to have a "certified solution" and shifting the trust from the specification to our team, which are real risks. – glcohen Jul 20 '21 at 17:49