fix (#1999) request url overwritten
Description
This PR changes how oauth2 authorization behaves. The current behavior is that user defined request is in most part overwritten by bruno and replaced with request for access token (following the specific OAuth2 flow). After this change, the token request will be executed separately, and obtained access token will be used to modify the user request's Authorization header.
Credentials caching
In order to avoid renewing access tokens for each request, bruno will cache the authorization response data. This information typically contains: access_token, token_type and some optional fields: refresh_token, expires_in, scope, session or whatever authrization server decides to include. The cached data is collection specific, and will be used if present. It may be cleared using clear cache button, together with other oauth2 session state.
Automatically using token if token_type is bearer
After obtaining access token from authorization server or from cache, bruno will verify what is its token_type. At this point bruno understands bearer type, so if that's it - the user's request will be modified - the Authorization Bearer $access_token header will be added automatically, so the request should be successful. In cases where the token is of different type (e.g. mac encrypted) - bruno will not attempt anything, but user is free to use scripting capabilities to work with the token in any way they see fit. Support for other token_types may be added in the future, if there's a demand.
Scripting
The token (and other data from authrization server response) are also available in scripting engine. The req object now includes the .credentials field where they can be accessed in post-request script (and if #2249 is fixed, also in pre-request scripts). E.g. this is possible:
bru.setVar('token', req.credentials.access_token);
More work is required for feature completeness:
- Better UI for token management. (#2077 )
- Display access token req/res in the Timeline (drafted in #2253)
- Possibly support token lifecycle (understand expiration time, auto renewal using refresh token #2437 )
- Possibly support other token_types
Contribution Checklist:
- [ ] The pull request only addresses one issue or adds one feature . - this cannot be said here
- [ ] The pull request does not introduce any breaking changes - it would affect user relying on scripted workarounds.
- [x] I have added screenshots or gifs to help explain the change if applicable.
- [x] I have read the contribution guidelines.
- [x] Create an issue and link to the pull request.
resolves #1999
This may be superseded by a more complete #2077.
Thanks for the work on this @pietrygamat !
We are reviewing this as a part of our broader effort to bring in OAuth2.0 interface improvements.