[keycloak-dev] Cross Client Use case
bburke at redhat.com
Mon Apr 13 11:00:27 EDT 2015
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?
> Sent from my iPhone
>> On Apr 13, 2015, at 9:37 AM, Bill Burke <bburke at redhat.com> 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.
>>> 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?
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>> Bill Burke
>> JBoss, a division of Red Hat
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
JBoss, a division of Red Hat
More information about the keycloak-dev