Closed kirk-marple closed 3 years ago
Are you facing the same issue with any OAuth2 provider? Can you try using the 'Request access token locally' option?
That's the only one I've tried, since it's the only one we use. I tried using the 'locally' option as well, and got same result.
With the 'locally' option selected, you'll be able to see the actual request to the access token URL in the Network tab of the DevTools window - http://blog.getpostman.com/2015/06/13/debugging-postman-requests/
Are you seeing the correct token in the Network tab?
I had trouble getting any network traffic to show up in the Chrome dev tools, but I'm using Fiddler, and have captured the traffic during the token request.
Do you know exactly on which request I'd see the token? In the callback to /oauth2/callback?
The POST call to your access token URL should have the access_token.
I think I'm seeing the issue here. Auth0 is returning "id_token" and "access_token". id_token is the JWT. If I paste the valid id_token into the Authorization header, it works fine.
Maybe Postman doesn't have a way to grab id_token from the Auth0 callback?
I found this page: https://ask.auth0.com/t/how-to-test-auth0-secured-apis-using-postman/1146
And used this link to create a token https://auth0.com/docs/auth-api#!#post--oauth-ro
{ "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlF6UkJOa001UlRaR1F6UkRSVFV4UmtWRVJUUTFRekkyUXprNVFURTNSRVZHTURFME1VSkNOdyJ9.eyJpc3MiOiJodHRwczovL2NhbmRlbGEuYXV0aDAuY29tLyIsInN1YiI6ImF1dGgwfDU2MDFiNTRlYmVmNjYxY2MzZjZkNmVlMSIsImF1ZCI6IjJ1T0QwR2pQd0NneHJ0ZlY3bjhFOVNHaW9ONUVnVUMwIiwiZXhwIjoxNDQzNjA1MDU4LCJpYXQiOjE0NDM2MDE0NTh9.BDYmXfYyAWYdOIQMOrcL8LZjOfG90_uaGBkuc88w_5rrsoy40SPVRMr0XeLew7V4H_4IfpFGUVjq7w0RpmhpXApQZEOR6qZhnC-9nKP4XdrIPzqUKPh4mLgtYbngchsnsnpineHQsdz2N6xEqB2f_nIaosylh0LisU9MWWmcyYEPgAgmAalZIlvjqaIcgmX4YlZ_KKF0NOTBO_ivJ-xjdbz2-y2JY3AY7mvI_sPRUqo9Jh2XHAnuPSw6aEurJghY8PyHGINBauf_AUvhiAeaTsbzaMoAamGyoldW4pM_wBqsRZN0f50I19ZJ5mYVlR46sBbbv9psdxREH0jYAUTQ9g", "access_token": "hl1YiSaJPYA6He1Z", "token_type": "bearer" }
@kirk-marple Most providers use access_token to store the actual token which is meant to be used to make the request. We can fallback to id_token if access_token is not found, but the default will always be access_token. We're working on customizing this part of the OAuth flow.
I'm working with Microsoft Azure AD as an OAuth provider, and they also use id_token as the actual JWT. But they also provide the access_token, meaning that it would never fall back to id_token.
I think this issue really bogs down to implementing OpenID in Postman
Hey guys, can report that Auth0's is also using id_token for storing the JWT. Any updates with this?
Would love to see simple configuration to choose which parameters to use, as my provider is also providing the JWT in id_token
where access_token
is an opaque string.
@vikiCoder Is this a valid issue?
@DannyDainton Yes, it is valid. We are exploring some ways to enable these workflows
This duplicates #492. We will track this in a single place and close this request.
Is possible to access this id-token like the other variabled? eg. {{managedTokens.id_token}} I need a way to add these tokens as additional headers.
Appears like this token is being truncated after calling Auth0 to generated it. Looks like the call succeeds, and the client ID/secret are OK, but this token is much, much shorter than it should be. (Trying to decode it with jwt.io fails, understandably.)
access_token → 3tj3qc5xEnvI09dq
Any ideas?
Thanks, Kirk