As of ueberauth 0.7.0, On every /callback request, Ueberauth checks for a state param. On the initial request, this works, but ueberauth_cognito's hack of redirecting users to /callback?refresh_token= does not include a state param, so the request fails as a csrf forgery.
Instead, users of this library should have a way to use a refresh token to request a new access token from the authorization server without going through the client. Two potential options I see:
Remove refresh token support from the library, since the recommended way to use it is both broken and causes a (minor) security problem.
Expose a function to the application that lets it pass a refresh token to cognito outside of the normal ueberauth strategy flow, so it can be used transparently.
It may be worth depending on an oauth2 library instead of writing everything from scratch.
As of ueberauth 0.7.0, On every
/callback
request, Ueberauth checks for astate
param. On the initial request, this works, but ueberauth_cognito's hack of redirecting users to/callback?refresh_token=
does not include a state param, so the request fails as a csrf forgery.Ueberauth doesn't have built in support for refresh tokens, but ueberauth_cognito's hack to send the refresh token to the client and read it from
/callback?refresh_token=
violates the spec: Refresh tokens MUST be kept confidential in transit and storage, and shared only among the authorization server and the client to whom the refresh tokens were issued. It also requires two extra redirects for the client compared to updating the access token transparently (to/callback?refresh_token=
, and then back to the intended page).Instead, users of this library should have a way to use a refresh token to request a new access token from the authorization server without going through the client. Two potential options I see:
It may be worth depending on an oauth2 library instead of writing everything from scratch.
Included for reference: Cognito docs