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

Stian Thorgersen sthorger at redhat.com
Mon May 2 09:10:57 EDT 2016


I wasn't thinking a token exchange, I was thinking it would just do a new
authentication request with different scope, etc..

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>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 listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://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 Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160502/8d038146/attachment.html 


More information about the keycloak-dev mailing list