On Apr 13, 2015, at 9:37 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: Our tokens are JsonWebSignatures. If the other applications have the public key of the realm, they can verify those signatures. Keycloak also has a remote validation URL which you can send a token to. /auth/realms/{realm}/protocol/openid-connect/validate?access_token={token} > On 4/12/2015 6:58 AM, Raghu Prabhala wrote: > We have a use case similar to the one listed in the below url - > basically once a user is authenticated, a client application after > receiving the tokens from the Provider, shares the tokens with a few > other applications that are in a group. The other client applications > should be able to verify the tokens without requiring any more user > interaction. In the OIDC world, unfortunately, the aud parameter has the > clientid of the first app only and it will fail validation by the other > apps. So, is there any way this can be handled in KC? > > https://developers.google.com/identity/protocols/CrossClientAuth > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Apr 13, 2015, at 11:00 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: We do not have this capability. Submit a JIRA and I'll eventually add a ProtocolMapper than can add additional audiences. Alternatively, your applications could have their own internal list of valid audiences. Or, you could just ignore the audience when you validate. > On 4/13/2015 10:44 AM, Raghu Prabhala wrote: > Thanks Bill - I think the below info would be useful in case we decide to go for remote validation. But if we go for local validation of the tokens then we still have a problem as we typically verify signature, issuer, expiry time and even audience. The issue is that "aud" will have the clientid of the first app and hence it will fail validation at the second and third apps. To address that issue, I am wondering if KC can be enhanced to group a set of client applications and if any of the apps within that group communicates with KC, then KC puts in all the clientids of all the apps in the group in the "aud" parameter of the tokens? That would address the "aud" validation with the second and third apps. Is that something that can be done in KC? > > Thanks, > Raghu > > Sent from my iPhone > >> On Apr 13, 2015, at 9:37 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >> Our tokens are JsonWebSignatures. If the other applications have the >> public key of the realm, they can verify those signatures. Keycloak >> also has a remote validation URL which you can send a token to. >> >> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={token} >> >> >> >>> On 4/12/2015 6:58 AM, Raghu Prabhala wrote: >>> We have a use case similar to the one listed in the below url - >>> basically once a user is authenticated, a client application after >>> receiving the tokens from the Provider, shares the tokens with a few >>> other applications that are in a group. The other client applications >>> should be able to verify the tokens without requiring any more user >>> interaction. In the OIDC world, unfortunately, the aud parameter has the >>> clientid of the first app only and it will fail validation by the other >>> apps. So, is there any way this can be handled in KC? >>> >>> https://developers.google.com/identity/protocols/CrossClientAuth >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com