GEANT OIDC-work status
Janne Lauros
janne.lauros at csc.fi
Wed Nov 15 01:16:55 EST 2017
Hi!
>> Do you plan to support the other flows too?
Yes, we do plan that. We have already given that some thought and expect to start that work hopefully before end of the year. We just want to finish the implicit first.
BR Janne
----- Original Message -----
From: "David Langenberg" <davel at uchicago.edu>
To: "dev" <dev at shibboleth.net>
Sent: Tuesday, 14 November, 2017 21:50:27
Subject: Re: GEANT OIDC-work status
The problem with not having the auth flow though is that Implicit is forbidden in the spec from sending down a refresh token. One of the big draws to the OIDC world is the ability to issue refresh tokens and apps long-term access to your resources to act on your behalf without having to re-auth. This is especially key in mobile apps where folks expect to login only once and then never again unless they exceed some long period (way longer than our IdPs would ever be set to for SSO session) of idle.
Dave
--
David Langenberg
Asst Director, Identity Management
The University of Chicago
On 11/14/17, 8:25 AM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
> May I ask why you went with the implicit flow first (instead of the
> authorisation code flow)? Do you plan to support the other flows too?
The reason they started there was that it's much simpler to implement and matches the predominant SAML use case so it's easier to adapt the SAML examples to make it work.
I am extremely curious as to how people plan to test upgrades or changes in a world of back channel flows. There's a reason we stopped using them and I'm extremely loathe to go back to that. It's one thing to do it as a RP because that's what Google insists on, but it's a bad model to follow if we have the choice. I really think it's misguided if we're going to do a profile for higher ed to codify what we already learned a long time back was a mistake.
-- Scott
--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
More information about the dev
mailing list