Non-standard OIDC flow: How safe is this?

Question

I have been made aware of an application, at a client, that claims to use OIDC to authenticate users. This is however done via a non-standard flow that I find hard to assess from a security standpoint.

It starts with a frontend SPA initiating an OAuth2 Implicit grant with the openid scope. Important to note is that this is not an OIDC Implicit grant as only an access_token is returned. The token is then used in communications to the backend API, which uses the token to request attributes from the userinfo endpoint. The user is considered authenticated as the user returned from userinfo.

My first assessment is that this should be fine, as long as the TLS certificate on the userinfo endpoint is validated. However, I am not comfortable stating this to the customer since the flow seems to lack some of the key parts of OIDC, and I have never seen this flow promoted anywhere by anyone.

Answer 1

I can't see a vulnerability in the described flow. However, a lot of much smarter and competent people work on standards, such as OIDC. And there is probably a reason why they designed it the way they did. So I would argue using a non-standard flow is dangerous, even if the problem is not immediately obvious to us.

Answer 2

This flow might be susceptible for access_token injection.

As far as I can tell from your description of the flow, there is no reason to use the implicit grant with some custom additions instead of the authorization code grant, which is more secure than the implicit flow. Implicit grant will be removed in OAuth 2.1 for good reasons.

In case of a SPA with a backend, the BFF (Backend for Frontend) pattern might be interesting, where the backend does all OAuth stuff and leaks no token to the frontend which is more secure than handling e. g. refresh token in the frontend.