0

I've read that the silent authentication is typically made in a 1px iFrame. What I've been wondering is how the response to the authentication request is passed back from the iFrame to the parent application. Only option i can think of is that the Auth-Server returns some javascript code that runs e.g.

window.top.postMessage('auth', 'thisisthetoken')

But that approach seems a little sloppy to me. So how does it work?

Jan
  • 47
  • 9

1 Answers1

3

That is the traditional flow for token renewal in Single Page Apps. The initial authentication should be done on a main browser window via a redirect, eg as for Google Sign In or Office 365.

TOKEN RENEWAL LIBRARY USAGE

The oidc client library is commonly used to implement this, enabling the iframe post to be done with very little code.

IFRAME MECHANICS

The main window triggers an OpenID Connect redirect on a hidden iframe. When a response is received, the iframe uses the postMessage API to return an OpenID Connect response to the main window, containing code and state parameters. The main window then exchanges the code for tokens, using a PKCE code verifier that it saved to session storage before triggering the iframe redirect.

BROWSER SUPPORT FOR THIRD PARTY COOKIES

The above flow relies on the Authorization Server's SSO Cookie being sent in the iframe request, but browsers are starting to drop third party cookies to limit tracking - Safari already does this.

Therefore it is now standard to instead manage renewal via a secure cookie issued for the site of the web origin, and to avoid iframe post solutions.

Projects that rely on third party cookies these days will struggle - see this recent answer of mine.

HOSTING PREREQUISITES

In 2021 you are best to use secure SameSite cookies in the browser, since posting tokens between frames is vulnerable to Cross Site Scripting. Ensuring that the web origin of each frame can share a secure cookie via a child / sibling domain is therefore a prerequisite - you cannot really develop a secure web solution these days without it.

Security in the browser is a tricky topic and needs an architectural design - for more info on 2021 web security recommendations, take a look at recent Curity Web Guidance.

WITH TOKENS ONLY

This will work buy is considered very poor security in 2021:

  • Redirect the whole window to authenticate the user (good)
  • Save tokens to local storage (bad) - to deal with page reloads - easily exploited by malicious code
  • Then post tokens between iframes (bad) - can be intercepted by malicious code that adds a listener
Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • The webapp I'm building uses multiple iFrames as components. Each of those iFrames requires authentication. For security reasons I don't want to pass a token from the parent to each of the iFrames. That's why I want each of my iFrames to authenticate themselves. Thats why i can't have a redirect on every Component. My question was rather out of curiosity how it works. I'm aware that those librarys are capable of doing that. – Jan Sep 10 '21 at 18:39
  • Is only the intial request to load the iframe considered a third party request and thus the cookie blocked? Wouldn't that mean that i could load the authentication page of the auth server which then does a checkauthenticated call and returns the token? I can't really use a secure cookie on the site of the web origin due to the structure of the page. – Jan Sep 10 '21 at 18:50
  • I added some more notes above - basically you can't rely on the SSO cookie (since it is third party) - though (for now) it is sent on full browset GET redirects. I would test on Safari if possible, since it is the strictest browser. You may need to discuss with architects etc who design hosting domains. – Gary Archer Sep 10 '21 at 19:16