GEANT OIDC-work status

[David Langenberg]

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
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5202 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20171114/09be5ccf/attachment.p7s>