[keycloak-dev] Some OIDC JIRAs to fix?

[Stian Thorgersen]

On 1 July 2016 at 14:44, Marek Posolda <mposolda at redhat.com> wrote:

> On 01/07/16 08:58, Stian Thorgersen wrote:
>
>
>
> On 30 June 2016 at 16:25, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I am adding some OIDC specs JIRAs with possibility how to fix them. I am
>> including those, which will be easy to fix and I can look into them later
>> today or tomorrow before PTO :
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3189 - Add 'typ' to JWT header
>>
>
> +1
>
>
>> <https://issues.jboss.org/browse/KEYCLOAK-3190>
>> <https://issues.jboss.org/browse/>https://issues.jboss.org/browse/KEYCLOAK-3190
>> - Add 'kid' to JWT header
>>
>
> +1
>
>
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3217 - UserInfo endpoint not
>> accessible by POST request secured with Bearer header
>>
>
> +1
>
>
>> <https://issues.jboss.org/browse/KEYCLOAK-3147>
>> https://issues.jboss.org/browse/KEYCLOAK-3147 - OpenID Connect auth
>> request redirect_uri behaviour not according to spec
>>
>
> +1 To just require redirect_uri in either case
>
> We need separate JIRAs for scope=openid and another one for removal of ID
> token when scope=openid isn't used
>
> For now, I've created https://issues.jboss.org/browse/KEYCLOAK-3237 for
> both things.
>
>
>
>> <https://issues.jboss.org/browse/KEYCLOAK-3222>
>> <https://issues.jboss.org/browse/>https://issues.jboss.org/browse/KEYCLOAK-3222
>> - WellKnown endpoint doesn't return supported types of client
>> authentication
>>
>
> +1
>
>
>> <https://issues.jboss.org/browse/>https://issues.jboss.org/browse/KEYCLOAK-3219
>> - WellKnown endpoint doesn't support claims_supported
>>
>
> Maybe this one isn't so straightforward due to protocol mappers?
>
> Yes, right. Just publish it with some value will be easy (and probably
> will make OIDC test happy :) ) but tricky part is which value to use...
>
>
>
>>
>>
>> All of those are quite straightforward and easy to fix IMO.
>>
>>
>> Besides that, there are those 2, which I first rather want to confirm
>> what exactly to do:
>>
>> - https://issues.jboss.org/browse/KEYCLOAK-3221 Tokens not invalidated
>> if an attempt to reuse code is made
>>
>> We have just single-use code (which is good), however OAuth2 specs
>> recommends to invalidate existing tokens if an attempt to reuse code is
>> done. And one OIDC test is in WARNING state because of it (it tries to
>> access UserInfo endpoint with the accessToken issued with the reused code).
>>
>> I can see 2 possibilities to fix:
>> a) Invalidate just single clientSession where "code" attempt reuse was
>> made
>> b) Logout whole userSession
>>
>> It looks to me that (a) is sufficient solution. The potential issue with
>> (b) is, that if attacker can steal code, it gives him the possibility to
>> trigger global logout of user from all apps. WDYT?
>>
>
> I think option (a) is the correct approach. I interpret the spec to state
> that tokens associated with the specific code should be invalidated. Option
> (b) seems a bit over the top and not necessary I also wonder if there's
> non-malicious situations where an application could try to exchange a code
> twice, for example after a timeout or an automated connection retry?
>
> Not sure if this can be really an issue... Maybe we can fix and see if
> someone see issues?
>

It's not an option if we go with (a), but it's a potential issue if we go
with (b). We may not even know the correct user session if the client
session doesn't exist. My vote is let's stick with option (a).


>
>
> Marek
>
>
>
>>
>>
>> - https://issues.jboss.org/browse/KEYCLOAK-3218 Support for "max_age" in
>> AuthorizationEndpoint and "auth_time" claim on IDToken
>>
>> The possibility to implement is :
>> - Add new note AUTH_TIME to UserSessionModel. It will be time when
>> authentication of user was fully finished (including requiredActions).
>> Session note is used just so we don't need to change the model ;)
>> - If "max_age" parameter was requested, the "auth_time" will be added to
>> IDToken (or I will re-check specs if we should rather always add it to
>> IDToken)
>> - I am also thinking about adding hook to CookieAuthenticator, so that if
>> max_age parameter was used and userSession authTime is too "old", the
>> CookieAuthenticator will be ignored and user will need to re-authenticate
>> with other authenticators (username/password form etc). Then authTime will
>> be updated on userSession once authentication is finished.
>>
>
> +1 Sounds good
>
>
>>
>> WDYT?
>>
>> That will leave us with bigger things for OIDC Basic certification (
>> scope parameter support, possibly 'claims' param support and 'acr' support).
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160701/3b6c27c8/attachment-0001.html