Does this Oauth implementation also supports refresh_token grant type ?
Because I notice after testing that I’m getting a new pair of access Tokens and refresh tokens on every click on Single-Sign-On. Theoretically if as a user I already Authorized an app, I should get a refresh token that lasts some days/weeks depending on the oauth server config, and in a new request by the same user just use this refresh token to get a new access ( And thus avoid getting the authorize thing everytime )
To clarify, right now the flow is something like this:
https://seafile/accounts/login/ SSo link:
we click on authorize, is POST to the same url, which generates an authorization code and we are redirected to the redirect_uri:
It will be possible in case we detect is a user that already authorized, hence he has a refresh token, to reply directly with the refresh token ?
Or seafile expects that we land with the code parameter ? If we could also send the refresh_token instead of a code, then it could get a new token directly using this one, and thus making a standard Oauth2 implementation.
So we reply with:
and internally seafile just get’s the access token with this instead of the authorization code:
$ curl https://mysso/de/oauth/token TestClient:TestSecret -d 'grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
Then we will get also an access_token, but without generating a new refresh_token:
Is there any plans to support this ?