[keycloak-user] Token Exchange AWS Cognito & Keycloak

Fri Apr 12 06:28:57 EDT 2019

Hi Pedro,
i'll try to reply to your questions:

- We've configured Cognito as an identity provider in Keycloak, importing
the configuration via the OIDC discovery-configuration endpoint. At this
point we needed to introduce the clientID & secret, so we've created a new
confidential client inside AWS Cognito and used its id &secret in the
Keycloak's Identity provider config

- We've set the permission & policy about token exchange feature to our
Keycloak client

- The SRP flow leverages the SRP authentication protocol (so basically, no
password is sent to the server). The result of this flow is a couple of JWT
tokens (access and id token), but the access token doesn't respect the OIDC
rules (it doesn't contain the openid scope). This last point is what make
the token exchange process impossible (this because, during the process,
Cognito replies that "the token doesn't contain the openid scope"). About
that i want to highlight the fact that these problems are entirely Cognito
related: if we use a standard OAuth2 Flow (like Authorization code grant or
implicit) the process works as expected.

- Since the SRP flow enables us to use a self-hosted login page which
doesn't send the password directly to the server, we've tried to find other
solution. So we've tried to provide to the token exchange endpoint the id
token, changing some parameters of the HTTP call. And at this point
something unexpected for us happened: the token exchange process works also
providing the id token. Here's the reason of my first flow of questions: is
this behaviour expected? Is the "exchange with id token" approach a
feasible and good one? Or is completely a bad approach?

- Since using this flow (SRP) force us to provide the id token to our
backend side, here comes the other flow of questions :). From an OIDC point
of view, can be a right approach accessing a backend resource from a single
page application, using an id token? I've always read that if you want to
access to a backend resource, from a client application, is better to use
the access token, because the id token contains a lot of user informations
and must be used only by the client application.

- Here's the curl of the token exchange process with the access token (i'm
omitting some infos):

curl -X POST \
-d "client_id=test" \
-d "client_secret=<client_secret>" \
--data-urlencode
"grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
-d "subject_issuer=<alias_of_the_identity_provider_in_keycloak>" \
-d "subject_token=<access_token>" \
--data-urlencode
"subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
-d "audience=test" \
http://localhost:8080/auth/realms/<realm_name>/protocol/openid-connect/token

- Here's the curl of the token exchange process with the id token (i'm
omitting some infos):

curl -X POST \
-d "client_id=test" \
-d "client_secret=<client_secret>" \
--data-urlencode
"grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
-d "subject_issuer=<alias_of_the_identity_provider_in_keycloak>" \
-d "subject_token=<id_token>" \
--data-urlencode
"subject_token_type=urn:ietf:params:oauth:token-type:id_token" \
-d "audience=test" \
http://localhost:8080/auth/realms/<realm_name>/protocol/openid-connect/token

Let me know if you need more infos.

Thank you again,
Matteo Restelli

On Wed, Apr 10, 2019 at 3:40 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> So you are doing external to internal exchange. It is not clear to me how
> you configured AWS Cognito as an identity provider and what/how the SRP
> flow works. Could you provide more details, please? Is the token issued by
> Cognito a JWT ?
>
> In addition to that, how your token exchange request looks like when using
> both id_token and access_token as a subject_token ?
>
> On Wed, Apr 10, 2019 at 9:56 AM Matteo Restelli <mrestelli at cuebiq.com>
> wrote:
>
>> Any news on that?
>>
>> Thank you!
>> Matteo
>>
>> =============================
>>
>>
>> Hi all,
>> We're using AWS Cognito as our Identity provider for our platform. We're
>> trying to use an internal instance of Keycloak, in order to check the
>> possibility to use KC for authorization purposes (this because Keycloak
>> has
>> a wonderful and powerful authorization system that fulfill our needs, and
>> for that i want to say you "Thank you very much" :) ). For this reason we
>> want to use the token exchange feature of Keycloak.
>> More specifically we want to follow this flow:
>>
>> - User authenticates on AWS Cognito via SRP auth flow (which basically is
>> not a standard OIDC/OAuth2 authentication flow)
>> - User sends the access token to contact the backend service and, in the
>> middle, this token is translated to an internal one, minted by Keycloak
>>
>> If we provide the AWS Cognito access token to the token exchange endpoint,
>> with the subject_token_type parameter set to
>> "urn:ietf:params:oauth:token-type:access_token", an error is returned
>> stating that the access token doesn't contain the "openid" scope. Despite
>> this we've tried another way, providing the id token to the token exchange
>> endpoint with the subject_token_parameter set to
>> "urn:ietf:params:oauth:token-type:id_token", and we discovered that this
>> alternative way works. So, my questions are:
>>
>> - Is the "exchange with id token" approach a feasible and good one? Or is
>> completely a bad approach?
>> - From an OIDC point of view, can be a right approach accessing a backend
>> resource from a single page application, using an id token? I've always
>> read that if you want to access to a backend resource, from a client
>> application, is better to use the access token, because the id token
>> contains a lot of user informations and must be used only by the client
>> application
>>
>> Thank you very much,
>> Matteo
>>
>>
>> PS:  As a side note, i want to clarify that if we follow an authorization
>> code grant flow, or an implicit flow, during the authentication against
>> AWS
>> Cognito, the access token exchange works as expected. So this means that
>> the problem is related to the shape of the token released by Cognito.
>>
>> --
>>
>> Like <https://www.facebook.com/cuebiq/> I Follow
>> <https://twitter.com/Cuebiq>I Connect
>> <https://www.linkedin.com/company/cuebiq>
>>
>>
>> This email is reserved
>> exclusively for sending and receiving messages inherent working
>> activities,
>> and is not intended nor authorized for personal use. Therefore, any
>> outgoing messages or incoming response messages will be treated as company
>> messages and will be subject to the corporate IT policy and may possibly
>> to
>> be read by persons other than by the subscriber of the box. Confidential
>> information may be contained in this message. If you are not the address
>> indicated in this message, please do not copy or deliver this message to
>> anyone. In such case, you should notify the sender immediately and delete
>> the original message.
>>
>> --
>>
>> Like <https://www.facebook.com/cuebiq/> I Follow
>> <https://twitter.com/Cuebiq>I Connect
>> <https://www.linkedin.com/company/cuebiq>
>>
>>
>> This email is reserved
>> exclusively for sending and receiving messages inherent working
>> activities,
>> and is not intended nor authorized for personal use. Therefore, any
>> outgoing messages or incoming response messages will be treated as
>> company
>> messages and will be subject to the corporate IT policy and may possibly
>> to
>> be read by persons other than by the subscriber of the box. Confidential
>> information may be contained in this message. If you are not the address
>> indicated in this message, please do not copy or deliver this message to
>> anyone. In such case, you should notify the sender immediately and delete
>> the original message.
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>

-- 

Like <https://www.facebook.com/cuebiq/> I Follow  
<https://twitter.com/Cuebiq>I Connect 
<https://www.linkedin.com/company/cuebiq>

This email is reserved 
exclusively for sending and receiving messages inherent working activities, 
and is not intended nor authorized for personal use. Therefore, any 
outgoing messages or incoming response messages will be treated as company 
messages and will be subject to the corporate IT policy and may possibly to 
be read by persons other than by the subscriber of the box. Confidential 
information may be contained in this message. If you are not the address 
indicated in this message, please do not copy or deliver this message to 
anyone. In such case, you should notify the sender immediately and delete 
the original message.