I'm working on an iOS app which uses login via linkedin. I'm using a web view for the user to login and getting the token from linkedin. If i understand it correct, The token which i received is valid for short period and hence i need to make a call to linkedin with the existing token to get a new token with the extended period. Can you please let me know what api I should call to refresh the token to get the new token with the extended validity?
I'm currently using https://github.com/jeyben/IOSLinkedInAPI
According to LinkedIn there is no direct API to call to refresh a OAuth 2 token. What's supposed to happen is if:
The user is logged into LinkedIn
They have a current (less than 60 days old) token
pointing them to the authentication url will trigger a refresh of their token, without needing the user to log in.
In using the iOSLinkedInAPI library, this didn't seem to be the case.
What I figured out was, the authentication flow wasn't generating a login session cookie from LinkedIn in the iOS simulator or on a device, so requirement 1 was never being met.
You need to have the user login through the regular LinkedIn login page, and this gets you that session cookie, which you can cache. After you send the user to authenticate your app, you can load that cached cookie into the NSHTTPCookieStorage sharedHTTPCookieStorage each time you want to call the authentication URL to refresh the user's token.
I created a helper class with an example if you want to check that out:
iOSLinkedInTokenAuthorizer
Related
I have implemented a google oauth signup.
I can request the tokens with the code provided when the user clicks login via google.
However, the tokens only include the refresh token the very first time that the user signs up/logs in.
All later attempts to get tokens with the auth code only return an access token, but not a refresh token.
I have to manually revoke the app permission in the user's google settings in order to force a new permission prompt which provides me with a new refresh token.
Is there some way to request a refresh token with the auth code? I.e. not just during the first login.
I found the solution. The refresh token is only sent with the response when the consent screen is shown to the user. This only happens during the first login and once the user grants the permission the screen will not be shown anymore.
However, it is possible to force show the consent screen, which results in the refresh_token being sent.
You can do this by adding
prompt=consent
to the oauth url.
or if you use the php api you can set it like this:
$client->setApprovalPrompt('consent');
I am working on graph api to get user's liked pages videos. I have read https://developers.facebook.com/docs/ and requested for user_action.videos from Facebook. Now things becomes more confusing for me when i read about 1- OAuth Authentication, 2- temporary/long-lived access token and 3- test user as well.
1- As i believe as per my reading that OAuth Authentication for user is not required as it is done by FB SDK automatically. Is it right and if its wrong then how to authenticate user while using FB login dialogue as there is no URLRequest call in latest FB SDK login button?
2- After login through dialogue, I am getting an access token which is an expiry token and to keep user logged into my App; I have to convert that expiry token to long-lived token for 60 days every time when token is going to expire?
3- Is there any need for creating Test User in Facebook developer portal. Is there any role of it in development?
Any help would be greatly appreciated.
The normal flow for OAuth2 as described in this SO reply is as follows:
Send API request with access token
If access token is invalid, try to update it using refresh token
if refresh request passes, update the access token and re-send the initial API request
If refresh request fails, ask user to re-authenticate
This is all well and good for most API calls, but I wonder one thing: Authentication.
When a user attempts to sign in to my fancy new webapp using their favourite service, should I use their refresh token (or cached access token in the case of OAuth1) to attempt a sign in, or should I always go and get a fresh token from the service provider (Google, Facebook, etc) and discard the stored access and refresh tokens?
User authentication and OAuth 2.0 are two different things. The difference is explained in detail in: http://oauth.net/articles/authentication/. Even when building user authentication/SSO protocols on top of OAuth 2.0 - which is what OpenID Connect does and some vendor-specific implementations - the refresh_token still always applies to the access_token not to the user authentication event or identity token.
You can not use a refresh token on its own to refresh a user's login session since some interaction with the user (may be active, may be passive) through the browser is required to confirm that the user is (still) present.
To refresh a user's login session you will always have to redirect to the identity provider and get fresh authentication information. Note that that interaction will probably also give you a new refresh token that could be used to refresh the access token.
I have a website where people can post blogs. I want the blogs to be automaticly posted to a Linkedin account connected to the website. So the person posting the blog is not the owner of the linkedin account.
I use the Sharing API from LinkedIN to do this, but this requires the administrator of the linkedin account to refresh the Oauth token every 60 days. I know this is a security thing to prevent illegal use of accounts. But in this case its always my own linkedIN account. Is there a way around this? mabe by using the app key and secret instead of the acces token?
The LinkedIn API docs (https://developer.linkedin.com/documents/handling-errors-invalid-tokens) say:
In the case the access token is already expired, your application will
go through the same authorization flow as previously described.
However, the login dialog will be shown to the user as they will need
to grant access to your application again.
so there's no way around that. But what you could do is go through this flow before the access token has expired. The docs say:
Simply have your application go through the authorization flow in
order to fetch a new access token with an additional 60 day life span.
When the following conditions exist:
User is still logged into Linkedin.com The current access token isn't
expired (within the 60 life span) We will automatically redirect the
user back to your redirect_uri without requiring them to reauthorize
your application. If they don't exist, we'll prompt them to login and
then redirect them.
I'm using the Doorkeeper gem to provide OAuth in a Rails app. The client is a Chrome extension.
I have 'use_refresh_token' commented out in doorkeeper.rb, and 'access_token_expires_in' set to 1 minute. I thought that would force the client to re-auth after a minute. But re-auth is happening automatically, regardless of whether use_refresh_token is present or not.
With use_refresh_token present, a new row is added to 'oauth_access_tokens' every time the access token expires. No new row is added to 'oauth_access_grants.'
With use_refresh_token commented out new rows are added to both tables. Which I would expect if the client was manually re-authing. But it appears to be happening automatically--the user is granted access without having to re-auth the app through the OAuth login screen, as I'd like.
Apologies for my ignorance, I'm new to both Doorkeeper and OAuth and haven't found any clues on Google et al.
The OAuth 2.0 is working as it is sending authorization URI to authorize url to get the access token and while the user is not authorized to get token the server redirect him to login page, I think the point in your case that the expire in time is too short so the session opened when user entered username and password for first time still valid so when your client asking for new token it is getting it as the user is still loged in on the authorization server, you can change the time of session to be less than the token validity time and test it.