According to the reference link https://developers.trello.com/authorize, I choose the first way Using the Authorize Route to implement OAuth on Trello.
The involved url request is https://trello.com/1/authorize?return_url=http://xxx/union/callback/trello&namae=xxx&key=xxx&callback_method=xxx&scope=read&expiration=30days
Finally, the program stops with url http://xxx/union/callback/trello#token=a1418eb97b298edc9a7a83fb85107bad4d2861cf46ac897037002aff778c3927 on the browser location.
In my opinion, token should be returned after "?" instead of "#".
Because string after "#" will not be sent to server.
For this issue, is it a bug of trello's OAuth or I can do anything to proceed ?
Related
I have been trying to implement Google and Github OAuth authentication in one of my projects which uses React on the client side and NodeJS-Express on the backend. After going through dozens of articles and several Youtube videos later, here's what I have discovered about OAuth.
There are two main flows in OAuth. Authorization Code Grant Flow and Implicit Flow. To be on the same page, I would elaborate what I understood about both of these flows in short:
Authorization Code Grant Flow : User(resource owner) clicks on Login with Google/Github and is then redirected to the consent screen. Once they give consent, user(resource owner) is redirected back to the callback_url with a authorization_code in the URL query parameter. The authorization code is then send to the backend server. The server then makes a request to the authorization server of the OAuth provider along with the client_id,client_secret and the authorization code and then receives a access_token as well as a refresh_token required to access the resource server.
Implicit Flow : It is sort of a hacky way that was proposed back in the day for Single Page Applications as CORS wasn't properly implemented in all the browsers. Here the Single Page Application is given the access_token once the resource owner has given consent to the OAuth provider and it is now the duty of the SPA to store the access_token in a protected manner. However, since browsers aren't really trustworthy, and CORS is a real thing now, the Implicit flow is not really recommended anymore.If someone wants to implement the Implicit FLow, PKCE (Proof Key for Code Exchange) is sort of the standard now.
What I tried to implement
I decided to go ahead with Authorization Code Grant Flow as it seemed the most secure to me and also I have a backend server to handle the authorization code exchange.
Here is what most people suggest in order to implement Authorization Code Grant Flow with React.
Render a link like this.
<a href='http://localhost:8000/auth'>Login With Github</a>
Now handle this endpoint in the backend
app.get('/auth',(req,res)=>{
res.redirect(githubOAuthConsentScreenURL)
})
Now handle the redirect_uri in the backend and make a post request to the authorization server to get a access_token
app.get('/auth/callback',(req,res)=>{
//Extract the authorization code from query params and make a POST request to get back the access_token
})
Passport JS also implements this approach which is handling the callback url on the server.
Here is what I thought of doing:
Handle the callback URL on client side i.e. with React. Extract the authorization code from the parameters and then make a XHR call to the server with it. The server will now exchange the authorization code for an access_token and make a request to get the user's profile data. If everything succeeds, the Express backend will return a short lived access_token and a long lived refresh_token which will then be used by the React application to access the REST API.
My question here is : Which method is correct and the standard way to do authentication, handling the callback_url on the server or on the client side?. The method I propose over here seems more logical to me. Does my method have any security flaws compared to the other one? Am I missing something?
Other things that I have confusions about :
How is OAuth vulnerable to CSRF? From what I read, the state parameter can be used to protect the OAuth flow against CSRF. However, if I am redirecting the user from my backend server and then handling the callback_url in the server as well, how do I remember the state variable apart from storing it in some sort of session/db. Is it not more logical to redirect the user from the browser? Then the state parameter can be stored in the localStorage and can be matched later during the callback.
Also, I am implementing a short lived access_token and a long lived refresh_token for authentication and storing both the tokens as httpOnly cookie. If my access_token is stored as a httpOnly cookie, then how do I know if I am logged in or not and persist the state in React. One solution (proposed by Ben Awad in this video) was to query for the user during initial load and if the query succeeds, store the state (maybe in Redux) and then conditionally render the routes.
Is this the correct way of doing this? If not what is the standard manner that is followed by React applications which are actually in production? Again, am I missing something here?
Please Note : I am pretty new to authentication, would appreciate all the help and detailed explanations.
My goal is to tell if a user is authenticated, and get their name and email. So far, I can only do the first.
My server app is a NodeJS/Express router. The OIDC server is provided by my company, I believe is compliant, but not under my control. I can do an "Authorization code flow": response_type="code". My Node app eventually responds to the callback route and I can get the "code" and "grant_id" query string values. Other than knowing they exist and presuming that means the user is authorized, I have no idea what I can do with those values. It appears that the only scope that works is "openid".
If I can get the access_code, I can call the UserInfo service and get these values.
My other choice is to do an implicit call. Unfortuantely, the OIDC service it provides the "access_code" and other values after a hash mark on the callback. I believe the flow to be like this:
User makes call to Node app. Detects a lack of authentication, issues redirect to SSO service implicit authorization
User's browser follows redirect to SSO service implicit authorization. User fills it out and is successfully authenticated.
W3 returns a redirect to the provided callback URL.
User needs to cooperate with the app, somehow parse the query string parameters to get the access token and pass this back to the Node application.
The browser calls the provided Node callback application, but without the necessary access token.
I think I could make a proxy server to force OIDC to give my node server the request, just so I can get the access_token. It seems like a very convoluted way to do this, so I have to think there's some simpler way.
Again, all I want is to know the user is authorized to use the app, and what their name and email is. It should not be this hard.
You can use the ID-token to get the details about the user.
It is also important that your identity provider is all about authentication. Final authorization checks should be done in the client, by examining the scopes/claims in the token.
I have set-up a basic site using nodejs and and jwt access tokens. Everything works fine but I'm having trouble working out the flow when a user first comes to the site. With cookies you already have that data stored in the browser so you can know if a user is logged in upon arrival and can route them accordingly. But with JWT tokens it's different. When someone types in URL and the request hits the server it doesn't have that access token until the page is returned and you retrieve the token.
I have some ideas of what I can do, but I want to make sure I'm doing it properly. What is the proper way to handle this? Is it simply to return the page, retrieve the accesstoken then make another ajax call to the server to verify the token and then route them accordingly? That seems like the logical solution, but maybe I'm wrong.
I am new to the DocuSign integration. It seems I need to use the OAuth Authorization Code Grant so I am doing a GET with something like this:
https://account-d.docusign.com/oauth/auth?response_type=code,&scope=signature,&client_id=my_integrator_key,&state=some_string,&redirect_uri=my_callback_URL
I have set the Redirect_URI on the Integrator Key to be the same value as my_callback_URL above, and I have set a Secret Key (though I do not know what that is for).
When the logon page displays it shows this error in red above the email address box:
The client id provided is not registered with DocuSign.
I have spent quite some time trying to figure out why this is but no luck. I figure this is a common mistake but I do not see it.
Your redirect url is not right--do not include commas.
Your example should be:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=my_integrator_key&state=some_string&redirect_uri=my_callback_URL
Once your redirect_uri is called with the authorization code, you'll use your secret when requesting a bearer token for use with your API calls.
See the docs.
Assuming your my_callback_URL query parameter corresponds to a valid redirect URI you configured, and seeing that you are hitting the demo OAuth endpoint, are you possibly trying to use the production system?
To login to DocuSign's demo (sandbox) environment you go through:
https://account-d.docusign.com/#/web/login
To login to your live production account go through:
https://account.docusign.com/#/web/login
I would like to add your Instagram feed to my website. I post pictures on Instagram here. How Can I do this. https://www.instagram.com/developer/clients/manage/ at this address, a new client I have created. I'm doing but something is missing. I couldn't do with Instafeed.
i guess u stuck with the place about access token.. u should approve Client-Side (Implicit) Authentication..
If you are building an app that does not have a server component (a purely javascript app, for instance), you will notice that it is impossible to complete step three above to receive your access_token without also having to store the secret on the client. You should never pass or store your client_id secret onto a client. For these situations there is the Implicit Authentication Flow.
Step One: Direct your user to our authorization URL
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
At this point, we present the user with a login screen and then a confirmation screen where they grant your app’s access to their Instagram data. Note that unlike the explicit flow the response type here is “token”.
Step Two: Receive the access_token via the URL fragment
Once the user has authenticated and then authorized your application, Instagram redirects them to your redirect_uri with the access_token in the url fragment. It will look like this:
http://your-redirect-uri#access_token=ACCESS-TOKEN
Simply grab the access_token off the URL fragment and you’re good to go. If the user chooses not to authorize your application, you’ll receive the same error response as in the explicit flow