why scope set to dummy for authorization_code and refresh_token

[gravypower]

Summary

I am wondering why scope is set to dummy for authorization_code and refresh_token

oauth2-mock-server/src/lib/oauth2-service.ts

Line 211 in 752f93a

scope = 'dummy';

should this also just repeat back the requests scopes like client_credentials does?

[nulltoken]

@gravypower 👋 Sorry for the delay in getting back to you.

Could you please share a bit of context with regards to your question? Are you facing an issue or a possibly unexpected behavior?

[gravypower]

thanks for responding @nulltoken. I am wanting to generate a JWT with scopes using the auth code flow. I expected that this library would just echo the scopes back like what happens with the client id and audience but this is not the case. I am working on the logic that applies authorisation in an app but was not able to do this with out forking the code base and removing where the scope is set to dummy.

I think doing this was correct but wanted to understand why dummy was set in the first place.

[nulltoken]

@gravypower Hmmm. I'm a little bit puzzled.

The code below defines an xfn transformer that will set the sub and amr and copy along the scope properties in the token payload to be generated.

oauth2-mock-server/src/lib/oauth2-service.ts

Lines 212 to 218 in 752f93a

	xfn = (_header, payload) => {
	Object.assign(payload, {
	sub: 'johndoe',
	amr: ['pwd'],
	scope,
	});
	};

This transformer is later passed to buildToken

oauth2-mock-server/src/lib/oauth2-service.ts

Line 236 in 752f93a

const token = await this.buildToken(req, tokenTtl, xfn);

This test showcases how an passed in scope is retrieved in the decoded token payload

https://github.com/axa-group/oauth2-mock-server/blob/master/test/oauth2-service.test.ts#L543-L573

In the end, I'm not really sure what doesn't work as you would expect and why you had to fork the code base.

Could you please help me understand better the problem you're facing?
(Or if it's quicker for you, a failing unit test showing what should work and doesn't)

[gravypower]

I have altered that test you linked me to show the issue, see how when the grant type is authorization_code the scope is always dummy.

I think the issue is here:

oauth2-mock-server/src/lib/oauth2-service.ts

Line 211 in 752f93a

scope = 'dummy';

it('should allow customizing the token response through a beforeTokenSigning event authorization_code', async () => {
    service.once('beforeTokenSigning', (token, req) => {
      expect(req).toBeInstanceOf(IncomingMessage);
      token.payload.custom_header = req.headers['custom-header'];
      token.payload.iss = "https://tada.com";
    });

    const res = await tokenRequest(service.requestHandler)
      .set('Custom-Header', 'custom-token-value')
      .send({
        grant_type: 'authorization_code',
        scope: 'a-test-scope',
      })
      .expect(200);

    const key = service.issuer.keys.get('test-rs256-key');
    expect(key).not.toBeNull();

    expect(res.body).toMatchObject({
      access_token: expect.any(String),
    });
    const resBody = res.body as { access_token: string };

    const decoded = await verifyTokenWithKey(service.issuer, resBody.access_token, 'test-rs256-key');

    expect(decoded.payload).toMatchObject({
      iss: "https://tada.com",
      scope: 'a-test-scope',
      custom_header: 'custom-token-value',
    });
  });

[gravypower]

I am happy to raise an PR to address this, just wanted to know if this was done for a reason?

[nulltoken]

just wanted to know if this was done for a reason?

paging @poveden that may have a better view on this

[poveden]

Hi @gravypower this was introduced about 4 years ago. I think (if my memory serves me well) that it was added because some client library complained about them missing. Again, this was 4 years ago, so probably this is no longer the case today.

So, yes, please, raise a PR. Thanks!

We would like to start using merged changes. What is the release process?