[OPENAM-11445] Request to Customize OAuth2 Access Token Content Created: 26/Jul/17  Updated: 14/May/19  Resolved: 03/Apr/19

Status: Closed
Project: OpenAM
Component/s: oauth2
Affects Version/s: 13.5.0, 13.5.1, 14.0.0
Fix Version/s: 6.5.2, 7.0.0

Type: Epic Priority: Major
Reporter: Sachiko Wallace Assignee: Peter Major [X] (Inactive)
Resolution: Done Votes: 17
Labels: AME, CustomerRFE, FIN-PSD2-OB, OpenBanking
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicates OPENAM-8440 Pluggable OAuth2 Access Token Format Closed
relates to OPENAM-13608 OAuth Client Validation Extension Open
is related to OPENIG-3081 Support customized access tokens Resolved
is related to OPENAM-8440 Pluggable OAuth2 Access Token Format Closed
is related to OPENAM-10362 Allow encryption in JWT payload for O... Closed
Target Version/s:
Epic Name: Customizable Access Token
Support Ticket IDs:


This RFE is similar to OPENAM-8440, but not limiting to stateless token.

The current OAuth2 access_token is not pluggable.
For example a user makes a request:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded


OpenAM allows the users to return additional data via Scope Validator plugin class (ie. additionalDataToReturnFromTokenEndpoint() method). However, this is one time operation and is not persisted in CTS store.

It would be nice if there is a away to add custom field to tokens so it will be persisted in CTS store. Or if it's stateless token, it would be nice if OpenAM offers the ability to leverage a JWT format, with an additional scriptable component to control attributes within the JWT similar to the scriptable OIDC id_token.

Acceptance Criteria

  • We have a new script type of "Access Token modification"
  • On a Provider level I can specify an Access Token modification script
  • The modification script can override existing Access Token attributes (modification = add, modify, delete)
  • Script needs access to same context as the OIDC Claims script
  • Introspect endpoint is able to return modified attributes
  • Works for Stateful and Stateless tokens
  • Script should use CHF client (not Restlet)
  • The Access Token hash in idtokens (when provided) should be correctly calculated.
  • We need a default script as an example of how Access Tokens can be modified.

Comment by Andy Hall [ 23/Mar/18 ]

We would like an equivalent of the OIDC Claims Script for OAuth2 tokens themselves.

Comment by Paul Haggerty [X] (Inactive) [ 03/Apr/18 ]

We would like the same functionality as the previous comment requested,  an equivalent of the OIDC Claims Script for OAuth2 Access tokens. (Stateless  tokens)

Comment by Wayne Blacklock [ 23/May/18 ]

A banking prospect requested this today. To use for fine grain internal application access.

Comment by Volker Scheuber [ 06/Sep/18 ]

A media/telco prospect would greatly benefit from this functionality. They POC-ed with us and one of their use cases requires customized JWT oauth access tokens.

Comment by Andy Hall [ 04/Dec/18 ]

Elevated to an Epic for comparison with peer issues.

Comment by Mark Nienaber [ 07/Jan/19 ]

Hi Andy Hall understand your previous comment was only beginning of December, but any chance of a target on this?

Comment by Paul Haggerty [X] (Inactive) [ 25/Mar/19 ]

Do we know when this will be released? In 7.0 or 6.5.2?  We'd like to get this as soon as possible.


Comment by Andy Hall [ 26/Mar/19 ]

Paul Haggerty [X] Could you share your use case with us?


Comment by Kyle Burkhardt [ 02/Apr/19 ]

I'll add our use case, as this is important to us as well.  We have our username attribute as the Authentication Naming Attribute in AM, but it is not a permanent immutable value.  We are able to modify the id_token and userinfo through a custom ScopeValidator to set the sub value to something better fulfills the requirement of the OIDC spec.  However, we are not able to use stateless access tokens because the access_token will have the username and the 'sub' attribute since it is constructed via a different code path.

Comment by Peter Major [X] (Inactive) [ 03/Apr/19 ]

This is now implemented on master. The scripts have pretty much full access over the AccessToken instance, and anything can be changed. Fields can be removed, but it comes with the caveat that the access tokens may stop working when sent back to the AM instance.
The JavaDocs for the AccessToken interface have been updated with additional set/remove methods to provide control over the access token structure.
A default script also attempts to demonstrate the available functionality (all commented out though).

Comment by Andy Hall [ 08/Apr/19 ]

FYI scripts have access to client_id so easy to modify behaviour per client if needed.

Comment by Stephane Orluc [ 29/Apr/19 ]


Will it be included in v 6.5.2 ?


Comment by Andy Hall [ 29/Apr/19 ]

Stephane Orluc that is the plan yes.

Comment by Rohan Upasani [ 30/Apr/19 ]

Will the attributes get stored in refresh token as well? so when access token is issued with refresh token we will get the same attributes and /introspect of refresh token will return the custom attributes?

When you are planning to release 6.5.2?

Generated at Sun Sep 27 06:36:41 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.