You can tweak what goes into the access token through protocol mappers for a client or client template, so you need to write your own spec for how your own tokens look like. 

On 19 April 2016 at 11:26, Simon Gordon <dev@sgordon.totalise.co.uk> wrote:
Hi all

I'm looking at the future of our architecture, including how we secure APIs
(Resource Servers) and more.

It is important that any authorisation services we provide have versioned
and 'managed' endpoint interfaces, such that compatibility is maintained
across the lifecycle of the authorisation service (patches and upgrades).
Since our Resource Servers could be 'anything', we can't rely upon handing
out particular libraries for those resource servers to use to integrate
with the AS - that would be awful to manage across a large estate of
services anyway.

As I see it, I can mandate that Resource Servers use OAuth 2, so many
issues go away - but the critical item for maintaining compatibility is the
Access Token - when we implement the AS, a key deliverable to our RS
partners will be a technical specification of the Access Token.

Does a technical specification of the Access Token exist? What is the
policy with regards to compatibility of the Access Token across
versions/patches of KeyCloak?

(I could fall back to the Token Info endpoint - but again, that needs to
maintain compatibility across releases)

Thanks!

  Simon


_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user