[keycloak-dev] Some OIDC JIRAs to fix?

[Marek Posolda]

On 01/07/16 08:58, Stian Thorgersen wrote:
>
>
> On 30 June 2016 at 16:25, Marek Posolda <mposolda at redhat.com 
> <mailto: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/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 - 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/KEYCLOAK-3222
>     - WellKnown endpoint doesn't return supported types of client
>     authentication
>
>
> +1
>
>     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?

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 <mailto: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/2b7931b9/attachment.html