feat(IamAuthenticator): support refresh token flow in IamAuthenticator #146
Conversation
| ) | ||
|
|
||
| // NewIamAuthenticator constructs a new IamAuthenticator instance. | ||
| func NewIamAuthenticator(apikey string, url string, clientId string, clientSecret string, |
There was a problem hiding this comment.
This legacy ctor was simply moved down a bit.
padamstx
force-pushed
the
refresh-token
branch
2 times, most recently
from
27ba218
to
6fe42b5
Compare
padamstx
force-pushed
the
refresh-token
branch
from
6fe42b5
to
128532a
Compare
This commit updates the IamAuthenticator so that it supports the "refresh token" auth flow. In this scenario, the user constructs an IamAuthenticator with a refresh token (and client id/secret) instead of an apikey. The authenticator will use the "POST /identity/token" operation with grant_type "refresh_token" to obtain an IAM access token. In this commit, I also added a new "builder" for the IamAuthenticator as well, and deprecated the legacy ctor function although it is still supported.
padamstx
force-pushed
the
refresh-token
branch
from
128532a
to
20c9213
Compare
| // Validate ClientId and ClientSecret. | ||
| // If RefreshToken is not specified, then both or neither should be specified. | ||
| // If RefreshToken is specified, then both must be specified. | ||
| if this.ClientId == "" && this.ClientSecret == "" && this.RefreshToken == "" { |
There was a problem hiding this comment.
Is it possible that the API key was created without either the client ID or secret set? I guess there's a default that's used in that case but would the refresh token path use the default as well?
There was a problem hiding this comment.
Great questions...
When obtaining an access token for an apikey, there are no "default" values for client id/secret that are used if they're not specified. In this scenario, you won't get back a valid refresh token.
In order to obtain a valid refresh token, you must specify "bx/bx" for the client id/secret values along with the apikey.
So, if this refresh token is then going to be used to construct the IAM Authenticator, the same client id/secret values must be used as well. I didn't want to hardcode client id/secret to be "bx/bx" in the authenticator when a refresh token is being used because that seems a bit hackish. I discussed this with Martin Smolny and we settled on "the client id/secret values must be the same values that were used to initially obtain the refresh token", even though in the IBM IAM implementation those values an only be "bx/bx". However, in the future, this constraint might be relaxed to support additional values for those properties, but the "same as" constraint would still apply... presumably :)
# [5.9.0](v5.8.2...v5.9.0) (2021-11-29) ### Features * **IamAuthenticator:** support refresh token flow in IamAuthenticator ([#146](#146)) ([97f89dd](97f89dd))
|
🎉 This PR is included in version 5.9.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This commit updates the IamAuthenticator so that it supports
the "refresh token" auth flow. In this scenario, the user constructs
an IamAuthenticator with a refresh token (and client id/secret) instead
of an apikey. The authenticator will use the "POST /identity/token"
operation with grant_type "refresh_token" to obtain an IAM access token.
In this commit, I also added a new "builder" for the IamAuthenticator
as well, and deprecated the legacy ctor function although it is still supported.