[keycloak-dev] Some OIDC JIRAs to fix?

[Stian Thorgersen]

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/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


> <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?


>
>
> 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?


>
>
> - 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/e33c35e7/attachment-0001.html