René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Token endpoint scope parameter (avoiding ADSTS28003)","articleBody":"In a relatively obscure passage in RFC6749 it seems that token endpoint may also accept `scope` parameter:\n\n    [3.3](https://www.rfc-editor.org/rfc/rfc6749#section-3.3).  Access Token Scope\n\n    The authorization and token endpoints allow the client to specify the\n    scope of the access request using the \"scope\" request parameter.  In\n    turn, the authorization server uses the \"scope\" response parameter to\n    inform the client of the scope of the access token issued.\n\nWhen requesting multiple scopes for multiple audiences, Microsoft Entra refuses the authorization code to access token exchange with the message \n\n    ADSTS28003: Provided value for the input parameter scope cannot be empty\n    when requesting an access token using the provided authorization code\n\nThe application is supposed to re-use the authorization code (or use the refresh token if issued) and call the token endpoint multiple times to obtain multiple access tokens, one per requested scope. \n\nI wonder what should be the usable user interface for this in a tool like oauth2c. MSAL does it in a pretty ugly way (using an extra[extra_scopes_to_consent](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_interactive.params.extra_scopes_to_consent) parameter). \n\nLooks like I can't call the token endpoint two times with the same authorization code:\n\n    AADSTS54005: OAuth2 Authorization code was already redeemed,\n    please retry with a new valid code or use an existing refresh token. \n\nThe following sequence of curl requests seems to work:\n\n# Obtain the authorization code (token endpoint call will fail, but we use the authorization code)\n\n```sh\noauth2c \"$URL\" \\\n  --no-browser \\\n  --client-id \"$CLIENT_ID\" \\\n  --response-types code \\\n  --response-mode query \\\n  --grant-type authorization_code \\\n  --auth-method none \\\n  --scopes scope1,scope2 \\\n  --authorization-endpoint \"${AUTHORIZATION_ENDPOINT}\" \\\n  --token-endpoint \"${TOKEN_ENDPOINT}\" \\\n  --pkce\n```\n\n# Exchange authorization code for scope1 only\n\n```sh\ncurl \"${TOKEN_ENDPOINT}\" \\\n -H \"Origin: http://localhost:9876\" \\\n -d redirect_uri=http://localhost:9876/callback \\\n -d  code=\"$code\" \\\n -d code_verifier=\"$v\" \\\n -d grant_type=authorization_code \\\n -d client_id=$CLIENT_ID \\\n -d scope=scope1 \u003e token1\nREFRESH_TOKEN=\"$(jq -r .refresh_token \u003c token1)\"\n```\n\n# Exchange the refresh token for scope2 only\n\n```sh\ncurl \"${TOKEN_ENDPOINT}\" \\\n -H \"Origin: http://localhost:9876\" \\\n -d refresh_token=\"$REFRESH_TOKEN\" \\\n -d grant_type=refresh_token \\\n -d client_id=$CLIENT_ID \\\n -d scope=scope2 \u003e token2\n```\n\n# Refresh token for scope1\n\n```sh\nR1=$(jq -r .refresh_token token1)\noauth2c \"$URL\" \\\n  --no-browser \\\n  --client-id \"$CLIENT_ID\" \\\n  --grant-type refresh_token \\\n  --token-endpoint \"${TOKEN_ENDPOINT}\"  \\\n  --auth-method none \\\n  --refresh-token \"$R1\"\n```\n\n# Refresh token for scope2\n\n```sh\nR2=$(jq -r .refresh_token token2)\noauth2c \"$URL\" \\\n  --no-browser \\\n  --client-id \"$CLIENT_ID\" \\\n  --grant-type refresh_token \\\n  --token-endpoint \"${TOKEN_ENDPOINT}\"  \\\n  --auth-method none \\\n  --refresh-token \"$R2\"\n```\n\nIt looks like the refresh token \"knows\" which scope it should generate the updated access token for, but it is possible to specify the `scope` parameter anyway:\n\n```sh\nR2=$(jq -r .refresh_token token2)\noauth2c \"$URL\" \\\n  --no-browser \\\n  --client-id \"$CLIENT_ID\" \\\n  --grant-type refresh_token \\\n  --token-endpoint \"${TOKEN_ENDPOINT}\"  \\\n  --auth-method none \\\n  --scope scope1 \\\n  --refresh-token \"$R2\"\n```\n\nThis also works and generates a new access token for `scope1` and so on...\n\nOne implementation idea would be:\n\n1. We could add `--token-scopes` parameter (the actual name of the parameter would be `scope`) which could be added automatically for any calls to the token endpoint. \n\n1. The `--grant_type authorization_code`  could send `--scopes` to the authorization endpoint and `--token-scopes` to the token endpoint (both as the `scope` parameter).\n\n2. The `--grant_type refresh_token` could send `--token-scopes` to the token endpoint.\n\n3. Implicit grant never calls the token endpoint, so the `--token-scopes` could be ignored (or not accepted)\n\n4. Client credentials - I don't know - in that case `--scopes` and `--token-scopes` mean the same.\n\n5. Other flows - no idea yet.","author":{"url":"https://github.com/saper","@type":"Person","name":"saper"},"datePublished":"2025-04-17T19:20:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/130/oauth2c/issues/130"}