Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How is the refresh token used? #4

Closed
JonasGessner opened this issue Dec 8, 2016 · 6 comments
Closed

How is the refresh token used? #4

JonasGessner opened this issue Dec 8, 2016 · 6 comments

Comments

@JonasGessner
Copy link

JonasGessner commented Dec 8, 2016

The way I understood this guide is that you receive a refresh token and an access token. The access token is only valid for a limited time and when it expires you have to use the refresh token to get a new access token (instead of requiring the user to sign in again). How is this handled in this library and in combination with the Google API Objective-C library? The readme doesn't mention any token refresh request. Any clarification would be appreciated :)

@JonasGessner
Copy link
Author

I just went through GTMAppAuthFetcherAuthorization and OIDAuthState with a bit more detail and found my answer. The auth state handles everything and loads a new access token when needed. By assigning a stateChangeDelegate to the auth state you can update the keychain item for the authorization object when needed. That's the intended way to update the keychain item, right?

@skywalkerlw
Copy link

skywalkerlw commented Dec 13, 2016

@JonasGessner , appreciate if you could share some code snippets

I have the same question here.

  1. How can I know my token is invalid
  2. How to request token if invalid.
  3. Do I have to jump to a Webview and log in Google account again in order to refresh my token?

@JonasGessner
Copy link
Author

As I said in my last comment you don't have to refresh your access token manually. It's all handled automatically by the OIDAuthState (which is a part of the GTMAppAuthFetcherAuthorization). All you need to do is set the stateChangeDelegate of the authState of your authorization object and save the auth object to the keychain when the didChangeState: callback is called.

@skywalkerlw
Copy link

skywalkerlw commented Dec 13, 2016

One more question

What I have done here is:
Step1: log in my Google account for the first time, and persist authorisation via:

[GTMAppAuthFetcherAuthorization saveAuthorization:_authorization
                                        toKeychainForName:kExampleAuthorizerKey]

Step2: when you come back and launch the app days/weeks later, you still can get authorization via

GTMAppAuthFetcherAuthorization* authorization =
    [GTMAppAuthFetcherAuthorization authorizationFromKeychainForName:kExampleAuthorizerKey];

. So i can get the token again via : _authorization.authState.lastTokenResponse.accessToken, However I can not make sure myself whether this token is valid or not.

My question is: when and where to set "set the stateChangeDelegate of the authState of your authorization object"

Thanks

@skywalkerlw
Copy link

skywalkerlw commented Dec 15, 2016

Finally, i got the answer myself.

  1. we don't need explicitly to get token value and don't need to worry about token expire issue too.
  2. if you are on iOS side, instead use traditional http way, recommend to use : https://github.com/google/google-api-objectivec-client-for-rest , which could save you a ton of time

This thread tells everything: https://github.com/google/google-api-objectivec-client-for-rest/issues/75

@maztak
Copy link

maztak commented Mar 1, 2020

I faced same problem.
As two man said, we dont need to use refresh token and other method like authorization?.authState.tokenRefreshRequest().

I important thing, i think, we should get accessToken by authState?.lastTokenResponse?.accessToken. Dont save this token as the property, get it per each.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants