Oidc-client-js: Safari drops the fragment on redirect from authorization server. (previously: What web storage fallback do you recommend?)

[shaunluttin]

oidc-client-js appears to depend heavily on web storage. What do you recommend for browsers that do not support web storage?

[brockallen]

Which ones don't? http://caniuse.com/#search=web%20storage

[shaunluttin]

Hmm. Maybe the bug I am experiencing is not related the web storage then. Users are having trouble with mobile versions of Safari and also with Safari on Yosemite.

[brockallen]

What problems? Safari is notorious for dropping cookies once you get too many or they're too large.

[shaunluttin]

Since it is happening on a user's computer that I do not have, I have not been able to see the error message. It could be a wide variety of problems, of course, though I suspect it is a "no matching state found in storage" error, since what the user reports sounds similar to what that causes.

[brockallen]

There is logging in oidc-client, so you could listen for errors and capture them.

[shaunluttin]

Good idea. Shall we keep this issue open until I resolve what happened?

[brockallen]

Sure

[danactive]

@shaunluttin I can help debug using mobile Safari for iOS 10. Are the logs user facing?

[shaunluttin]

@danactive Yes. The logs are using facing, as far as I can tell.

[shaunluttin]

@danactive The problem is almost certainly this: http://stackoverflow.com/questions/18663410/safari-ignoring-removing-hashatags-when-clicking-hyperlinks

[danactive]

@shaunluttin I'll need step-by-step instructions as I'm not familiar with this problem or open source project

[shaunluttin]

@danactive Go to https://zamboni-app.azurewebsites.net and login. :)

[shaunluttin]

@brockallen So, the problem is definitely that Safari and other browsers are ignore the hash and everything after it. Do you consider adding that trailing slash to be a responsibility of the oidc-client-js or of those who are consuming it? /cc @pinpointTownes

[brockallen]

So, the problem is definitely that Safari and other browsers are ignore the hash and everything after it

When and in what context?

[shaunluttin]

When and in what context?

If we make this request to the OIDC server:

https://zamboni-auth.azurewebsites.net/Account/Login?ReturnUrl=%2Fconnect%2Fauthorize%3Fclient_id%3DAurelia.OpenIdConnect%26redirect_uri%3Dhttps%253A%252F%252Fzamboni-app.azurewebsites.net%252Fsignin-oidc%26response_type%3Did_token%2520token%26scope%3Dopenid%2520email%2520roles%2520profile%26state%3D8710fbd0233945499a7aa46bfee09af3%26nonce%3D00e849559d2b4b02a6b2d9cff6579598

After successful authorization in responds like this:

https://zamboni-app.azurewebsites.net/signin-oidc#state=8710fbd0233945499a7aa46bfee0...

Safari and other browsers like it ignore everything after and including the #.

[danactive]

Go to https://zamboni-auth.azurewebsites.net and login. :)

@shaunluttin "There isn't really anything to see here". This Auth Server home page has three lines of simple HTML.

If you want help, please provide steps to reproduce your issue

[shaunluttin]

@danactive Oops. It's https://zamboni-app.azurewebsites.net.

[brockallen]

Safari and other browsers like it ignore everything after and including the #.

Sounds like a browser bug.

[shaunluttin]

Sounds like a browser bug.

It depends on how we define a browser bug: http://stackoverflow.com/a/18698307/1108891

Also, it might be a moot question, because bug or not Safari is a major browser that has that bug.

In any case, I will be fixing the problem in the SPA that I have built. Do you think it is worth having that fix inside oidc-client-js or to leave it up to the consuming client?

[shaunluttin]

Indeed, the OpenID Connect spec shows that a successful response does NOT require the trailing slash before the hashtag.

https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj

[brockallen]

I still don't understand the issue. All you post here are statements like "it doesn't work". Other than saying the browser ignores stuff after the hash, there's no info here to repro your issue. And saying "just click this link" is not helping. You need to curate the info and post it here if you'd like help.

[shaunluttin]

Lol. Apologies for that. "It doesn't work" means that, since Safari is ignoring everything after the hash tag, the SPA is not receiving any of the content after the hash tag. The authorization server is responding with this:

https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj 

The SPA is only seeing this:

https://client.example.org/cb

The latter is not a valid response from the authorization server. The problems are many:

1. No state
2. No access_token
3. No id_token
4. No token_type

http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthResponse

[brockallen]

So then write yourself a test html page to confirm it outside of all the other moving parts. Please debug and research that it's really what you think it is. If safari really doesn't work, then find out what JS API is not working that this library relies upon and provide suggestions for fixing it by digging into the source code. This is how FOSS works.

[brockallen]

The SPA is only seeing this:
https://client.example.org/cb

You mean your server-side code only sees this?

[shaunluttin]

Nope. I mean my client-side code only sees that.

[shaunluttin]

Related: https://bugs.webkit.org/show_bug.cgi?id=24701

When a hash for a div or anchor is placed after an url that 301 redirects to another url, the hash is not kept when the redirect is executed.

[kevinchalet]

Do you consider adding that trailing slash to be a responsibility of the oidc-client-js or of those who are consuming it? /cc @pinpointTownes

I'm not sure this browser bug could be reasonably worked around by oidc-client-js itself if the "fix" consists in automagically adding a trailing slash before the fragment part: since https://client.example.org/cb and https://client.example.org/cb/ are two different URLs, the OP would immediately reject your authorization request and your app wouldn't work at all.

[shaunluttin]

@pinpointtownes So, it seems like it can be neither the responsibility of the oidc-client-js nor of the OIDC server to automagically insert a slash before the fragment. It seems like it must be up to the person who configures the oidc-client to ensure that the redirect_uri has a trailing slash.

Edit:: The oidc-client-js cannot automagically insert a slash, because the OIDC server would not recognize the redirect_uri. The OIDC server cannot automagically insert a slash, because the receiving client might not recognize the URL.

[brockallen]

Would changing your config to use "/" at the end of your redirect URI work?

[shaunluttin]

@brockallen Absolutely. Yes.

I took me a while to communicate the problem, and for that I apologize. I've been using this issue as an exploratory vehicle, which might not be the intent of GitHub issues in your repository.

The question above was about (well, eventually was about...) where the responsibility for appending that slash lies: from the dialog above, it seems like the config location is best.

One thing I might consider adding to the oidc-client-js (or to an OIDC server), is a warning/error while running, that indicates a missing trailing slash in the configuration.

Does all that make sense?

[brockallen]

I took me a while to communicate the problem, and for that I apologize.

Thanks for the apology. In the future (since this is the 2nd or 3rd time it's happened), I'd suggest getting all your info together before opening an issue or asking someone to fix something for you. OSS (and even more so for FOSS) is a group effort, so asking me or others to debug the issues you're having is asking too much. Sorry if this makes me an ass for saying it, but I was frustrated by these interactions.

As for the browser bug, I don't think either library should have to bend too far to support it. I don't know what side effects could arise from making automatic adjustments. Presumably it'll be fixed? And of course, you have a workaround without needing to make any library changes.

[shaunluttin]

Nope. It does not make you an ass. It makes you a good person for raising the issue. It's the only way I will ever learn.

[kevinchalet]

@shaunluttin if you really think it's a common trap, maybe it would be a good compromise to update processSigninResponse to log a more precise message when the OIDC payload can't be extracted from the fragment? Alternatively, it would be helpful to mention that somewhere in the wiki.

[shaunluttin]

The issue turned out to be the lack of a trailing slash at the end of our configued redirect_uri. The issue is related to WebKit bug 24701. Impacted browsers (such as Safari 9 on Yosemite) strip the hashtag fragment from redirects. The result is that, when the OIDC server correctly responds with this 302 Found redirect...

https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj 

...the client application receives only this...

https://client.example.org/cb

...because affected browsers strip the fragment. The downstream result for the oidc-client-js, is that it receives an invalid request at its redirect_uri and throws an error that says, "No state in response."

The fix is to make sure that the redirect_uri has a trailing slash, because the bug does not occur when there is a trailing slash before the hashtag.

var settings = {
    redirect_uri: 'http://localhost:5000/sign-in-oidc', // fails
    redirect_uri: 'http://localhost:5000/sign-in-oidc/', // succeeds
};

:watch:

[sattaman]

I've just been hit by this, very happy its an easy fix!

Seems to affect all logins on iOS , via Safari and Chrome.

[awangdev]

The '/' is definitely a common mistake, even suggested by Auth0 official guide (https://auth0.com/docs/quickstart/spa/angular2/01-login)

However, another mistake that I've encountered on the same thread, is about using 'redirect' on my nodejs server. It seems to contribute to the lose of hash on safari browsers (or safari on mobile). I've always been redirecting to the home page by:

res.redirect('/')

Instead, on the server, using a sendFile will do the same job of vending index page, but it won't cause the lose of hash values.

app.get('*', function (req, res) {
    res.sendFile(distDir + '/index.html');
});

Though, I'm not entirely sure why safari behaves differently or what's the intention of stripping hash values in different cases.

[cosmoKenney]

My redirect_uri is: https://secure.mydomain.com/logged-in.html
This is based directly on the javascript client samples.
But, randomly my qa person gets the No state in response error. However I have yet to see it in development. How do I fix this since my redirect_uri is a full path to a file?