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.
Related
I have integrated microsoft teams in my project where a user can give us access to create meetings on teams on his/her behalf. But now I want to give the user a option to disconnect his/her account i.e. we will no longer be able to create meetings on user's behalf.
I am facing few problems in this flow:
I am unable to find an API where I can send request on user's behalf
to invalidate a access/refresh token.
If I remove the token stored at my end and then user again tries to connect their Microsoft account with our website it no longer asks for user's consent(which is basic requirement for OAuth) to give access to our app(if user is logged in Microsoft account on the browser he/she do not see the consent page and account is directly connected with our website and we get the refresh/access token).
Can someone help me on this?
At the end all what I want is when user tries again to connect his/her Microsoft account with our app he/she see the consent page(every time he tries to connect account) and then user clicks the allow button which will give us access and refresh token.
If the user has granted access to the application, Azure AD will issue an access token and a refresh token for the resource.
The lifetime of the access token is usually about 1 hour. During its lifetime, even if the application is deleted, it is still available, but you will not be able to use the refresh token to obtain the access token again.
1)To invalidate access token on users behalf, Refer this DOC.
2)For fetching the access token using the refresh token please refer this DOC.
Hope this helpful.
An alternative solution for prompting the user to the consent page is just simply appending the prompt="consent" in the OAuth2 URI prameters:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=code&client_id=xxx&redirect_uri=xxx&scope=xxx&state=xxx&access_type=offline&prompt=consent
_____↑↑↑↑↑↑
Here you can find the documentation about the parameters.
I'm following this article to understand refesh tokens.
In my case I have to connect to REST api using grant_type=password, and I receive a token with a 5 minute lifespan. So every 5 minutes I have to issue a POST request passing client-id, username & password to get a new acces token.
The other option would be to issue a POST with a grant_type=refresh_token, without having to send the username & password. In my case I'm consuming an api, so passing the credentials doesn't involve any action from the final user. For me it's just to params more to send on the POST request.
In both cases, I have to issue a new post every 5 minutes.
Is that the only advantage (not needing to pass credentials again) of using the reresh token or is there any other thing I'm missing?
Background info
OAuth 2.0 Password Grant
The Password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.
OAuth 2.0 Refresh Token
The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired.
This allows clients to continue to have a valid access token without further interaction with the user.
Consider this.
Lets say that i add my login and password for my twitter account to your application and you then use that to request access from twitter to may account to post. Three months later i have forgotten i have set your awesome app up to do something on my twitter account and i change my password. Your system will break.
Now lets say i used Oauth2 to grant you access to my Google drive account, your awesome app can now do what ever it needs to do on my drive account. Now three months latter i have again forgotten i gave your awesome app access, I have the memory of a gold fish you see. I change my password. Nothing happens your awesome app still has access.
Now consider this, With oauth2 i can grant you access to only read from my google drive account not update it (scope). That and the system knows its not actually me preforming the actions.
With client login (login and password) most of the time it appears to the system that it is the actually owner of the account making the requests. You can also not limit access with client login for the most part you have full access.
note
yes i am ignoring the part about both tokens returned being the expiration time time. Thats because for all intensive purposes they are the same but that depends greatly on how the auth server you are using is set up. They could be set up to only be valid for an hour or a day. They may give you different access scopes, again this differs greatly from auth server to auth server.
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.
As a user, how do I revoke authorization given to an app?
Or as an app, how do force a new authorization?
I did not see anything in the user page or in the API documentation regarding revoking:
https://accounts.autodesk.com/users/{{user}}/view
https://developer.autodesk.com/en/docs/oauth/v2/reference/http
No way to revoke from the admin console at the moment unfortunately. As an App you may request different set of scopes which should trigger the user to authorise it again
I'm writing an app that needs to periodically get reports and update campaigns for a few users. The app can access their accounts now when they login and authorize, but what I want/need is for oauth to give access to the app to access their accounts whenever the script has to run. Is this possible?
Yes, it's possible. The relevant documentation is here.
You need to add access_type=offline to your request for an authorization code. The user will then be prompted to grant offline access to your script in the consent screen, and once he accepts, the response to your app will include a refresh token. Refresh tokens don't expire and can be used to generate new access tokens.
Note that if you lose a refresh token, you'll need to request authorization from your use again, this can be done by including prompt=consent in the request.