Is this authentication flow secure?

user_11590303 0
Viewed 192

Goal

Embedding a form on a 3rd party website that can use 1st party authentication (OIDC, keycloak) to post to 1st party service protected via bearer token. (Think of something like a comment form à la disqus.)

It is acceptable that this flow does not allow refreshing the oidc bearer token.

Concerns

  1. Prevent clickjacking

  2. Control 3rd party websites allowed to use the form

  3. Isolate user info and token from 3rd party website

Approach

Visual representation of the approach in question

My current understanding leads me to believe that the concerns are addressed:

  1. To prevent clickjacking (like in iframe-embedded auth), the whole login procedure is performed in a new popup window (see image: open popup).

  2. Checking for window.opener and checking window.opener against a pass-list (see image: login landing) should ensure that login-landing is not embedded in an iframe, is not navigated to directly, and is only accessed in a popup from authorized websites. Checking the targetOrigin of the window.postmessage command should ensure that only authorized websites can successfully use the form.

  3. Having the web component (see image: 1st party web component) use an internal, sandboxed iframe from srcDoc to perform all user-info or token related actions should shield user-info and token from access by the 3rd party website. Using the internal iframe should also ensure, that the 3rd party website using the web component cannot intercept the postmessage event.

Questions

  1. Is the approach secure?

  2. Is there a more standardized approach to this problem which I do not know of?

Thank you for your input!

web-component keycloak openid-connect iframe
1 Answers

Ok, you learn something new each and every day.

I learned, that the approach i followed as shown in the question is not secure.

  • An iframe which is populated via srcdoc does obviously not count as a cross-origin frame. Well, d'uh. This means it is no viable protection against the 3rd party website. This isn't getting any better by slapping a sandbox attribute on it, as this is intended to provide protection in the other direction (protect 3rd party website from iframe content).

  • What might work is using a web component which includes a cross-origin iframe. But why bother the embedding 3rd party website with including a) a script and b) a web component tag? I can see no real benefit (in my use case) over simply using a cross-origin iframe.

  • The popup-remedy for clickjacking on the other side is a must.

This question & answer were sponsored by the 'first try to understand your tools before developing eleborate plans'-committee.

user_115903030
Related