[keycloak-dev] Thinking about step-up authentication and token timeouts

[Pedro Igor Silva]

----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, May 2, 2016 10:10:57 AM
> Subject: Re: [keycloak-dev] Thinking about step-up authentication and token	timeouts
> 
> I wasn't thinking a token exchange, I was thinking it would just do a new
> authentication request with different scope, etc..

AFAIK ...

In SAML, AuthnRequest may have a ForceAuthn attribute set to true to indicate that IdP must authenticate the presenter directly rather than
rely on a previous security context.

There is also a RequestedAuthnContext that can be used to specify an "authentication class" pretty much like the "acr_values" in a OIDC Authentication Request.


> 
> On 2 May 2016 at 14:54, Bill Burke < bburke at redhat.com > wrote:
> 
> 
> 
> 
> 
> I have no idea. What you are describing is different. Its scope, SAML
> probably has it, but I don't know what it is. You also describe a token
> exchange service
> 
> On 5/2/2016 4:56 AM, Stian Thorgersen wrote:
> 
> 
> 
> 
> Wouldn't saml support it fairly easily? It's just another auth request with
> SE different params?
> On 29 Apr 2016 16:19, "Bill Burke" < bburke at redhat.com > wrote:
> 
> 
> 
> Sounds great. I hope we don't have to implement this for SAML too ;)
> 
> On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
> 
> 
> 
> Clients should be able to obtain tokens with reduced scope and longer or
> shorter expiration, then later request new tokens with increased scope and
> different expiration. They should also be able to require different levels
> of authentication and also require re-authentication.
> 
> An application may for example:
> 
> * At first only need users email - this would allow showing the name + email.
> In this situation a long expiration access token in combination with
> implicit flow would do. It's also not necessary to re-authenticate the user
> and a user that has been logged-in for months or even a year is fine.
> 
> * When a user clicks on orders it would require the password and extend scope
> to be able to view orders. Now you'll want to switch to short expiration
> access tokens and authorization code grant. You'll also want to make sure
> the user logged-in fairly recently, max 30 days could be sensible.
> 
> * When a user tries to purchase something the user now has to provide the OTP
> to be able to purchase with saved credit card details. You'll also want to
> make sure the user logged-in very recently, max a day could be required.
> There may also be cases where you always want the user to re-authenticate,
> for example when trying to purchase something over a certain price level.
> 
> 
> _______________________________________________
> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> Bill Burke
> JBoss, a division of Red Hat http://bill.burkecentral.com
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> Bill Burke
> JBoss, a division of Red Hat http://bill.burkecentral.com
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev