I am trying to practice the examples in the book "mining the social web". Unlike the applications I had created in twitter and facebook, the Oauth token and secret in the linkedin never show up. I only see my client ID and client secret.
by the way, since I do not have any personal url, can someone explain to me what is the appropriate URL I should enter? In the twitter and facebook applications, I just randomly entered some URL, like www.twitter.com, and it worked. In this application for linkedin, I entered www.linkedin.com, but no Oauth token comes out.
I know this question is too basic for you guys, sorry for posting this. I did google the solution for a while, but it seems like no one has ever posted this question.
You can't directly get an OAuth Token. You have to follow the authentication procedure to receive an OAuth Token.
Steps involved:
Configure your LinkedIn application with a valid callback url which your server is listening to.
Request an Authorization Code
Exchange Authorization Code for a Request Token
This LinkedIn link will help you on what parameters to send in each request and the URL for the same.
https://developer.linkedin.com/docs/oauth2
Related
I'm new to OAuth2 and I'm trying to understand the whole flow of things. For context, I'm thinking of making a web dashboard where users log in via Discord's OAuth2 API.
This is how I think the flow works based on my understanding so far:
User goes to my site and clicks a login link
My site redirects them to Discord with my client ID and a redirect URL #1 in the query string
Discord redirects them back to my site at redirect URL #1 with an authorisation code in the query string
My site takes this authorisation code and along with my client ID, client secret and redirect URL #2, uses all these to fetch an access token and refresh token from Discord
If I do get an access token, that means the user is now "logged in" (authorisation code worked)
My site finally redirects the user to a page and is now free to send requests to Discord's API with the access token, while saving the access token and refresh token. Just for example, say the page states their Discord username
I'm learning from this guide, and what confuses me is this code snippet from the guide. At line 5, it provides the redirect URL #2 mentioned above, in the query string. I'm not sure what it's for.
Also, I'm not very sure how to continue once I have the access token. If multiple users log in, I'd have multiple access tokens on hand. Say a user wants to access the page again, how do I uniquely identify them and know which access token to use to send requests to Discord's API? (for this example, the request would give me their username which I'd display on the page)
Yeah, I probably got a lot of concepts wrong. Any clarification would be greatly appreciated!
Edit: I've done more research into this, and found a much better guide here.
For my question about the second redirect URL, the examples in the official documentation specify a redirect_uri when doing both an access token and a refresh token exchange. However, this new guide makes do without for their access token exchange. Perhaps they missed it out? As this other stack overflow question says:
As an added measure of security, the server should verify that the redirect URL in this request matches exactly the redirect URL that was included in the initial authorization request for this authorization code. If the redirect URL does not match, the server rejects the request with an error.
I suppose this means that after the first access token exchange, any refresh token exchanges or straight up API requests with access tokens need to match the original redirect_uri of said first access token exchange. So I should use one and only one redirect_uri, and the refresh token exchanges/API requests do not actually use the redirect_uri, rather it's used for further security.
As for the whole login procedure, it seems I have to link the access & refresh tokens I obtain to a user session, and for that I'll look into using this passport strategy, passport-discord. Then, once the session expires, I'll discard the two tokens, and they'll have to click login again, but I can make use of this prompt option:
prompt controls how the authorization flow handles existing authorizations. If a user has previously authorized your application with the requested scopes and prompt is set to consent, it will request them to reapprove their authorisation. If set to none, it will skip the authorization screen and redirect them back to your redirect URI without requesting their authorization.
From there I think I'd just store the new access and refresh tokens associated with that user.
I'd really appreciate if any mistakes in my thought process could be pointed out!
Your summary seems good to me Mr Cloud - worth clarifying whether you are developing an SPA or (old) web app with a server side. Most commonly the first is cookieless, whereas the second stores a refresh token in a cookie. A key thing is to understand what the OAuth message workflow looks like. For SPAs and APIs this write up of mine may help you clarify what you want: https://authguidance.com/2017/09/26/basicspa-oauthworkflow/
Happy to answer any follow on questions ..
You can use the implicit grant to use with SPA
https://discord.com/developers/docs/topics/oauth2#implicit-grant
I have really hard time trying to understand mostly how should I implement my authorization flow. I think I have the authentication flow mostly correctly implemented using the technologies I've listed in the title. Here's what I want to achieve:
Basically I have a mobile app built using React-Native and I have made a restful API for this mobile app to use. I am currently at the point that I have implemented authentication using ADFS 4.0. My mobile app directly uses the ADFS endpoints to authenticate the user and I am able to receive the id_token and access token correctly from there. But here comes the part that I have no clue what to do next. Before I used openID, I had my own authentication and just an OAuth2 flow in my Spring REST Api and everytime I made a request from the mobile app to the API, I provided the access token in the headers, and used it to verify from the authorization server that the user is indeed authenticated and also received some crucial information about the user to use in my API. But now since I use OpenID-Connect and ADFS 4.0 for the authentication, I have the cruicial information I need in my API in the id_token. The question is, what exactly should i send to my API now from the mobile app, the id_token, access token or both? Given the access token to the userinfo endpoint at the ADFS returns the subject of the owner of the token. Like is there any way I could receive the users info using the subject or what exactly should I do. I've tried to research this subject a lot, but I am still very confused..
Send the access token to the API in the Bearer header. In the API, validate the token and, if required, do user info lookup. A Spring example of mine here if it helps.
Happy to answer any follow on questions ..
The OAuth User Token and OAuth User Secret actually expires in 60 days.
I looked at this link, but in my case this is not helpful.
What actually I do in my app:
I use oauth gem for authorization as below.
#linkedin_consumer = OAuth::Consumer.new(
API_KEY,
SECRET_KEY,
{ :site => "https://api.linkedin.com" }
)
linkedin_access_token = OAuth::AccessToken.new(#linkedin_consumer,OAUTH_USER_TOKEN, OAUTH_USER_SECRET)
Now by using linkedin_access_token I make api calls to get profile data. I get only linkedin id from the users, I never ask user to login in linkedin.com. So, how can I refresh it. please reply ASAP. Thanks.
No endpoints for refreshing linkedin OAuth2.0 Tokens have been mentioned anywhere in their documentation yet. All they say is:
Provided that the user is already logged into LinkedIn, this flow
provides you with a simple way of obtaining a valid OAuth 2.0 access
token without forcing your user to authorize your application again
But having user logged into LinkedIn wont really solve the purpose of refreshing tokens in backend. OAuth1.0 does have a mechanism mentioned.
One useful discussion on this topic I found : here
I modified google consumer to use in my application scenario.
My scenario is to authenticate user on our client's website and then log them into our system. I am able to do the following:
1) Get Request Token
2) Redirect them to the client's site. User enters username and password and they come back to our URL.
After this step I cannot get the access token.
var accessTokenResponse = google.ProcessUserAuthorization(); is always null.
Our client told me that when they return back to us they don't include the verifier and signed request token. I am not sure if that is the reason why I can't get this working.
Can someone please help? I am new to this.
Thanks
If you're doing authentication then your use of OAuth is probably inappropriate. You should be using OpenID of you're authenticating via Google.
As long as you're using OAuth, yes, the verifier string is mandatory.
I wanted to build a simple WP7 app to learn how to use Silverlight, so I thought I'd create a very simple yammer app. As a starter it would have two screens - Login (Username & Password) and Feed.
Yammer user OAuth for its authentication but I just dont get it! i appreciate you need to request a token to use the REST interfaces, but I dont want my users (even if its just me) to need anything other than their login credentials, as they would use on the website. In my head the token can be used in a similar manner as a forms auth token in asp.net
Am I missing something? But I cant see anything in the yammer documentation about logging in.
The process for OAuth is as follows
You do a token request to Yammer. If needed they will ask for yammer credentials and send a token back to a URL of your application
You must use that token to sign all your petitions.
You can't stop Yammer asking for credentials because that's the idea of OAuth. Yammer does not trust you and it's impossible for you to keep any user Yammer's credentials. That way they can't be stolen from your site. The more you can store is a temporal token.
There is a very good guide to using OAuth on hueniverse, which features an example workflow. It's not completely up to date with the latest version of the spec, although this probably doesn't matter too much for your purposes.