The sane approach to me is to extend the token introspection endpoint to be
able to introspect ID tokens.
Extending authorization endpoint with custom responses is just weird ;)
On Tue, 29 Oct 2019 at 21:23, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Yes, I was more thinking about re-using the authorization endpoint
+
prompt=none + id_token_hint with a custom response to indicate whether or
not the session is active. Similar to what some implementations do by
extending the introspection endpoint or something else.
On Tue, Oct 29, 2019 at 12:06 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> [Adding what we discussed]
>
> Authorization code flow should not be used as a backchannel API, but
> rather only as a redirect-based API through the user-agent. That is pretty
> obvious from the fact that all responses return a Location header. That
> means that the cookie should always be there as the user is authenticated.
>
> id_token_hint should never be used to re-authenticate, but rather only as
> a hint on the identity of the user as well as the session. If the id_token
> could be used to actually authenticate the user it would effectively become
> a user credential and giving a client full access to the user account, with
> the ability to obtain tokens for any client.
>
> prompt=none with id_token_hint can be used as a way to identify if the
> expected user is still authenticated, but only through a redirect (either
> directly or with a hidden iframe), not as a backchannel mechanism.
>
> On Fri, 25 Oct 2019 at 18:25, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
>> Hi,
>>
>> I would like to confirm that we don't support the `id_token_hint`
>> authorization request parameter.
>>
>> When in conjunction with `prompt=none` it is useful to re-authenticate as
>> well as check whether or not the session associated with the token is
>> active through a non-authenticated request (e.g.: no cookies set by the
>> OP).
>>
>> The use case I'm trying to solve is based on the assumption that you only
>> have/keep the ID Token, you don't want a front/back channel for logout
>> (e.g.: app is stateless), you need to check whether or not session is
>> active, and the check is done through a backchannel communication between
>> the application and the OP.
>>
>> Spec-wise, using either user-info or introspection endpoint is not
>> possible
>> if you only have the ID Token (although some implementations like Google
>> provide an addition `id_token_hint` to the introspection endpoint) given
>> that you should use the access token as a bearer.
>>
>> Wdyt ?
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>