I am creating a user login with the OAuth. Everything seems to work fine but Twitch redirect URI is messed up by the # where ? has to be.
My redirect URI:
https://localhost:7681/authorize
URI Twitch redirects to:
https://localhost:7681/authorize#access_token=43r99nhmxhvpckr4zrtb0sbx1q6tdg&scope=user%3Aread%3Aemail&state=%24%7Bdata.uid%7D&token_type=bearer
I already tried adding a trailing slash, nothing changed.
Did someone else encounter such behavior?
you requested a token for type token instead of a token of type code
token aka Implicit Auth is for client side apps and will generte and
return a access token via location hash
https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#implicit-grant-flow
“Normal” oAuth, aka " Authorization code grant" will return a ?code
that is to be exchanged for an access token.
https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#authorization-code-grant-flow
Essentially your <a href triggered the wrong token flow
Additionally you should never post generated access tokens publically.
Since someone can take it and abuse it or just revoke it. Or in this
case acquire your private email address.
https://discuss.dev.twitch.tv/t/why-is-twitch-oauth-redirecting-to-a-link-with-query-strings-separated-by/37976/2
Related
Friends, in the Authorization code flow, it states that after the /authorize call is initiated and success, the authorization code will be sent via HTTP 302 "redirect" URL to the client(say ReactJS webapp). Why the OAuth specification requires this to be sent in a redirect so the authorization code is sent in URL parameters exposed. I know it is recommended to use PKCE to handle this auth code leak issue, but my question is why OAuth spec requires us to send the auth code in 302 redirect in URL params in the 1st place. Why cannot the client(ReactJS webapp) place a simple GET request to the IDP and why cannot the IDP send back the auth code in the response body to the react JS application(say by xmlhttprequest). Any help is appreciated. Thanks.
If you use a OAuth2 service like Google, or some other service, and your react application would be able to handle the entire flow it means it can completely act on behalf of the user.
By requiring a redirect, it means that the user's own browser will go to the auth service's website, which is the only place the user can trust to safely enter their password and grant access to your application.
The URL in the addressbar means trust. Users are trained to never enter their password in a website they don't recognize.
I've been struggling with this and would love to see if any OAuth experts here have an answer.
For context, I'm trying to integrate OAuth into an existing first-party (internal) front-end client that lives on a subdomain. It's a single-page application. I have an authorization server that has an /oauth2/authorize and oauth2/token endpoint and I'm working with the OAuth 2 with PKCE authorization flow.
In all the examples I've seen externally, it seems like the recommendation is to make a top-level redirect to the authorization URL initial login . And for silently re-authenticating a user (if they were already logged in), using an invisible iFrame set to the authorization URL (and postMessaging the code back to the parent window).
I'm trying to understand what prevents me from making a front-channel request to my /authorize endpoint via Javascript. Something simple like...
const { state, code } = await fetch(authorizationUrl)
For the login case, I can handle a 403 error back from the AS and then redirect them to login from the client-side. For the re-authenticating case (i.e. client has an expired refresh token but is still logged in), this is great because I just get a 200 response and the code back directly in the JSON body and I can use it immediately. There is no top-level redirect, no hassle of saving app state, etc.
It seems like as long as the AS is willing to return the { state, code } via JSON, this should work. This means that
The AS authorize endpoint must be configured to allow CORS on select origins. This seems okay in a first-party context since I know which origins I should allow.
The AS must be sent client credentials (session cookies) with the request (otherwise the AS would have no idea how to determine if the user is logged in). In JS, this would be as simple as adding credentials: true. As long as the cookie credentials have Same-Site: None and the cookie is part of the same domain (cross-domain would not work since some browsers disable cross-site cookie sharing nowadays!)
I feel like I'm missing something crucial here. But at the same time, my prototype is working, so I'd love to get some input from experienced folks here.
Following this article from Auth0 Redirect Users from rules, we have the following scenario in our app:
User tries to login
for some specific criteria(s), they might be redirected to an endpoint which asks for challenge questions
if answered properly, the authentication mechanism resumes using the mentioned url:
domain/continue?state=STATE_GENERATED
We built a sample app, working well with one issue. The Auth0 generated 'state' can be seen by users; whether in redirects or in browser's network tabs.
So we tried the following:
login -> redirect to challenge question (state appended to url) -> we did not proceed but copied the state and launched the resume url in the browser:
https://DOMAIN.auth0.com/continue?state=THE_ORIGINAL_STATE
From within the same browser and it did a redirect to our app with a token. Users could mitigate challenge questions like that.
What is a best practice/recommended way to protect the 'state' in similar flows where Multi factor authentication is done using rules and redirect from rules?
The state is used to prevent CSFR in the authentication, it is not something that you can use to ensure a user has competed some action on your "challenge question" page. You should simply pass the state through.
What you need to do is use a shared secret to generate a token that can be passed from the challenge question page to the rule in order for it to be validated. Basically what you can do is after the user answers the question correctly, you generate a JWT token using a secret that both the challenge page server and the rule know. The JWT token can be anything, for example it could contain something like { challenge_success: true }.
After you generate the token you redirect back to:
https://DOMAIN.auth0.com/continue?state=THE_ORIGINAL_STATE&token=GENERATED_JWT
Then in the rule you read and verify the token and check that the claim is as you expect.
You can see a full example of how this works here: https://auth0.com/docs/rules/current/redirect#how-to-securely-process-results
We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)
I am getting error while Login with oAuth for Instagram, it says the redirectURI is wrong. I have researched on it and I have checked many answers on stackoverflow but its not helpful for me.
Here is the complete detail of what I did in my application.
1) I set my ClientId in pList for redirect URI :
2) I have added ig and authorize while creating the URI:
3)Now, I set ClientID in Instragram API :
And Here is my RedirectURI :
https://instagram.com/oauth/authorize?response_type=token&redirect_uri=igdd5fb08a33444af0b2b9c9420e69bc35%3A%2F%2Fauthorize&scope=relationships&client_id=dd5fb08a33444af0b2b9c9420e69bc35
When I fire the URl after login, it gives me the following error:
Can anyone help to find out where I am going wrong ?
Thanks,
The redirect URI you're providing is not what you have defined in your client settings.
1) Go to http://instagram.com/developer/clients/manage/
2) For your desired client/application, look for REDIRECT URI.
3) Make sure you provide the same redirect uri in your request as it is defined in your client/application settings. In your case, https://api.instagram.com/oauth/authorize/?response_type=token&redirect_uri=REDIRECT-URI&client_id=CLIENT-ID
Note: You may provide an optional scope parameter to request additional permissions outside of the “basic” permissions scope.
Note: You may provide an optional state parameter to carry through any server-specific state you need to, for example, protect against CSRF issues.
At this point, we present the user with a login screen and then a confirmation screen where they approve your app’s access to his/her Instagram data.
4) Once a user successfully authenticates and authorizes your application, instagram will redirect the user to your redirect_uri with a code parameter that you’ll use to request the access_token like http://your-redirect-uri?code=CODE.
For more information to learn about authentication process [Link]
tl;dr. The Redirect URI you send to /authorized must be same as the registered URI in your app.