11:42 p.m.
Hi Bill - here is my understanding of the spec:
Section 3.1.3.7 of the core spec says that clients must validate the id tokens. The third
point of the same section says that "aud" can contain more than 1 element in
which case the fourth point says that the client should verify that "azp" is
present and the fifth point says azp should be verified against the client id
Now when an oauth client registers, it can specify multiple redirect Uris, corresponding
to diff oauth clients that wish to participate in a single sign on. When a user tries to
access first client and he is authenticated, the client just gets a code. If the code is
passed to the second client ( the first client could be web app and the second client
could be a database service) then the second client could get an Idtoken. The auth server
(key cloak in this case) would then list all the client ids in "aud" and specify
the second client in "azp" which will be validated by the second client.
The above is a valid use case in our organization ( authentication delegation). It gives
flexibility to the apps ( especially sensitive ones) to pick the apps they trust rather
than just participate in an organization wide single sign on.
Section 3 (openID provider metadata) of the discovery spec mentions that issuer is a url
using https.
Hope I make sense.
Thanks.
Sent from my iPhone
On Oct 30, 2014, at 4:58 PM, Bill Burke <bburke(a)redhat.com>
wrote:
Ivan, btw, looking at the library you are using, validation of the ID token is optional.
> On 10/30/2014 4:15 PM, Raghuram wrote:
> I tested with libraries based on Apache Oltu and even I noticed that realm name is
being sent in the Idtoken under "iss". "aud" is null when I included
multiple redirect Uris which is breaking the validation (as per openid spec).
"azp" is not being sent (it is optional unless more than 1 client is registered)
- expect that to be sent once I register two clients.
"aud" has been fixed in master.
"iss" still is the realm name. This is just a unique identifier for the realm.
And there is nothing in the spec that I could find that states that it must match the
token endpoint URL. It just has to be a URL that uniquely identifies the issuer. It is
something that is configured, or, found during OIDC discovery.
"AZP
Your interpretation of AZP is not my interpretation of AZP. #1. AZP is optional, we
don't have to include it at all. #2 It would only have the value of the client that
requested the token. In Keycloak, ID Tokens are generated and only given to one
audience.
> Used /account for userinfo end point that didn't work. Will provide more feedback
as I continue to test
As I said before, we do not support userinfo yet. Our access tokens are Json Web
Signatures signed by the realm and the content is an extended version of ID Tokens that
contains additional keycloak metadata.
> Fyi -My libraries were tested completely against a server implementation based on
Mitre's open Id connect and they are good.
It's on the roadmap to expand our OIDC support beyond the minimal requirements and to
validate it against other implementations. Just haven't gotten to it yet.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com