JWT with roles for Spring Security

I’m trying to setup Auth0 with an existing API using spring security. This API works with a single page app front end.
From what I understand I need to use JWT, and add custom claims that will contain my roles inside the JWT.

In order to retrieve the JWT I downloaded the javascript quickstart and modified it slightly to retrieve the access token and provide an audience and the roles scope. This is the content of my app.js:

window.addEventListener('load', function() {

    var lock = new Auth0Lock(AUTH0_CLIENT_ID, AUTH0_DOMAIN, {
    auth: {
    responseType: 'token',
    params: {
        audience: 'my audience',
        scope: 'openid roles'

  // buttons
  var btn_login = document.getElementById('btn-login');
  var btn_logout = document.getElementById('btn-logout');

  btn_login.addEventListener('click', function() {

  btn_logout.addEventListener('click', function() {

  lock.on("authenticated", function(authResult) {
    lock.getProfile(authResult.idToken, function(error, profile) {
      if (error) {
        // Handle error
      localStorage.setItem('id_token', authResult.idToken);
      // Display user information

  //retrieve the profile:
  var retrieve_profile = function() {
    var id_token = localStorage.getItem('id_token');
    if (id_token) {
      lock.getProfile(id_token, function (err, profile) {
        if (err) {
          return alert('There was an error getting the profile: ' + err.message);
        // Display user information

  var show_profile_info = function(profile) {
    var avatar = document.getElementById('avatar');
    document.getElementById('nickname').textContent = profile.nickname;
    btn_login.style.display = "none";
    avatar.src = profile.picture;
    avatar.style.display = "block";
    btn_logout.style.display = "block";

  var logout = function() {
    window.location.href = "/";


Using this app I’m able to login properly, but the token that I’m getting doesn’t reflect the roles of the user. (the roles are supposed to be added by a rule)

I’m getting a JWT that has the following:

  "iss": "https://blabla.auth0.com/",
  "sub": "auth0|blabla",
    "my audience",
  "azp": "blabla",
  "exp": 1495240761,
  "iat": 1495233561,
  "scope": "openid roles"

I’ve read that it might be because of the OICD specification etc, but not too sure.

Would any of you have recommendations on how I could get the proper JWT to access my API’s endpoints?

Update (follow-up question):

I’m now able to see the roles in my access token:

      "iss": "https://blabla.auth0.com/",
      "sub": "auth0|blabla",
      "azp": "something",
      "exp": 1495484775,
      "iat": 1495477575,
      "scope": "openid roles email picture",

However it seems like Spring Security is not able to read those roles.
This is my security config:

    protected void configure(HttpSecurity http) throws Exception {
                .forRS256("https://api.example.com", "https://blabla.auth0.com/")
                .addHeaderWriter(new CacheControlHeadersWriter())
                .addHeaderWriter(new XContentTypeOptionsHeaderWriter())
                .addHeaderWriter(new XXssProtectionHeaderWriter())
                .addFilterBefore(new CORSFilter(), ChannelProcessingFilter.class)

It seems like it’s able to authenticate me, but then I get a 403 status code.

I tried to change the rule to change the roles field syntax so it looks like this: "https://api.example.com/roles": "'ROLE_ADMIN']"
but still the same issue.

Here is the code for my rule:

    function (user, context, callback) {
      var namespace = 'https://api.example.com/';
      context.accessToken[namespace + 'roles'] = 'ROLE_ADMIN'];
      callback(null, user, context);

Any idea?

1 Like

If you’re already obtaining an access token that lists your API as one of the audiences then the likely cause for it to not include the information you expect is the rule implementation. More specifically, the correct way to add custom claims to the issued access token is to do something similar to;

function (user, context, callback) {
    const namespace = 'https://api.example.com/';

    context.accessToken[namespace + 'roles'] = "[your_roles_here]";

    callback(null, user, context);

The important parts are that you use context.accessToken to set your custom claims and that those same custom claims need to be namespaced (the namespace part is so that we ensure that there are no overlap between custom claims and OIDC claims; even future ones).

For reference information related to setting custom claims in issued tokens see:


It seems that JwtWebSecurityConfigurer will look at the scope claim to fill the authorities associated with the authenticated principal. Given that hasRole checks the authorities, but the actual role data is contained within a claim that was not used as source for the authorities then it fails.

The use of that library implies that the authorities will have to be available at the scope claim of the access token and then you can use hasAuthority to check for it. Note that this is my interpretation of how that library works; I might have missed some way to configure this, but I don’t think so as this issue suggests it needs to be the scope claim.

Hello. Would someone show me the code please? I have some questions and would like to take a look at the code to solve my doubts. Thanks!

1 Like


Hi everyone,

I’m sharing what worked for one of our customers and I think it might be useful.

Issue: I’m using the Authorization extension and I created a rule to put the groups and roles of a user into a custom claim in the access token for my API, under “[namespace]/groups” and “[namespace]/roles” respectively. That works just fine.

How to integrate the above with Spring security:
The customer created a rule to put the groups and roles into the scope field so that Spring can interpret it. However, Instead of pushing the roles and groups in to the scope claim, what you will want to do is to extract the Spring authorities from the JWT manually. This is covered in the Spring Security documentation here.

There are a few ways to do this, but one of our engineers put together this gist demonstrating how a custom extractor can be created and used. This may help you avoid needing to put non-scopes into the scopes claim.

Also, our engineering team is working on improving/updating our documentation on this.

Please let us know if you have any questions!


Thanks for providing this update Lily!