ive been doing a stephen grider course and he creates a google oauth client id with authorised js orgins as http://localhost:5000 and authorised redirect URI as http://localhost:5000/* and google accepts it. But when i try the same it throws me an error for redirect URI as Invalid redirect: Cannot contain a wildcard (*). And im not sure without this , further it will cause problems.Any way to solve this. Ive typed http://localhost:5000/ as a temp solution. Kindly suggest.
What ever course you are following must be very old I have been developing with Google for five years a wildcard redirect uri has not been allowed in that time.
Authorized redirect URIs
For use with requests from a web server. This is the path in your application that users are redirected to after they have authenticated with Google. The path will be appended with the authorization code for access. Must have a protocol. Cannot contain URL fragments or relative paths. Cannot be a public IP address.
Redirect uri must be a path to the file you wish to use to handle your authorization.
The redirect URL you configure to the API console must be an exact string match to the redirect URL you use in your app. So for example, http://localhost:5000 does not match http://localhost:5000/ or https:5000//localhost. Thus a wildcard will never work.
Furthermore, it's very unusual for a redirect URL to not have a path component. So something like http://localhost:5000/myoauth is more conventional. That's not to say that an empty path is impossible, simply that it's so unusual that it's more probable you have misunderstood OAuth somewhere.
However, note that you can configure several redirect URLs, so http://local:5000 and https://localhost:5000 and https://myliveservice.com/redirect
Related
I have 10 websites hosting in my IIS. A user clicks on a link in site 1, the secret value generated in server-side (of site 1), then I want to send this secret value (encrypt or hash) in URL (query string) to central site and decrypt/validate the value there, to be sure a user is coming from site 1 to proceed (and not from another websites).
I think it won't be something fixed string so users can make this URL themselves:
https://centralSite.com/process?param1=....¶m2=....&source_website=site1
It should be something like a one-time dynamic generated token.
My question is :
Can I achieve this situation in only ONE HTTP GET request?
Should I use encryption/decryption or hashing/validating (all server-side)?
P.S: I can't use POST or other HTTP verbs here.
P.S: I know about HTTP referrer, but it can be spoofed or be null in some situations.
P.S: All websites are serving on HTTPS protocol.
To be clear this question relates to v2.0 of the Azure AD API.
I've configured an allowed redirect url in the Application Registration Portal as http://localhost:3000 (I've also tried http://localhost:3000/_oauth/azureAd).
Yet, when requesting an authorization code, providing a redirect_uri containing a query string causes authentication to fail with the error:
The reply address 'http://localhost:3000/_oauth/azureAd?close' does not match the reply addresses configured for the application.
It appears as though query strings are not ignored when matching a valid redirect URL. This is a problem as the Application Registration Portal won't allow you to enter redirect URL's with query strings!
I am in the process of writing an accounts package for Meteor to support v2.0 of Azure AD and this is a requirement for Meteor OAuth packages to function correctly.
The ideal solution I imagine is that query strings are ignored when validating redirect URL's
The Application Registration Portal doesn't support the a query string and invalid special characters.
As a workaround, you may create several redirect URL instead of using the query string. But would you mind sharing the reason why you need to use the query string in URLs?
You can avoid Meteor appending ?close to the redirect_uri by specifying a loginStyle configuration option. See: http://docs.meteor.com/api/accounts.html#Meteor-loginWith
Explained here (snippet below): https://github.com/meteor/meteor/blob/abd574f38008b45f5e2a6bc322b10bcdde44763a/packages/oauth/oauth_common.js#L3-L8
// XXX COMPAT WITH 0.9.0
// The redirect URI used to have a "?close" query argument. We
// detect whether we need to be backwards compatible by checking for
// the absence of the `loginStyle` field, which wasn't used in the
// code which had the "?close" argument.
In OAuth 2 when you add your client you give it a redirect url.
e.g.
http://example.com
But when you request authorization for a user, you also pass back a redirect url as part of the request.
e.g.
authorize?response_type=code&client_id=CLIENT_ID&return_url=http%3A%2F%2Fexample.com%2Fsecure%2F&state=STATE
My question is basically, what is the point in storing the redirect url against the client? Is this just for security to make sure you ONLY redirect to the original website and not whatever is passed as part of the request?
In any case what I have found is that the return url parameter sent as part of the request isn't honoured e.g. http://example.com/secure and the redirect url saved against the client is always used... and therefore you don't get redirected to your original request but just the home page.
What should happen? And why do we have the return url twice?
Should it not just be the domain stored against the client and then the return url passed back is used and then the domain compared for security?
This is indeed a security measure so that responses are only sent to URLs that have explicitly been associated with a client at registration/administration time.
The client may register multiple Redirect URIs and in that case it is useful to use the redirect_uri query parameter in the request to indicate to which one of the registred values the server needs to send the response. In case there's only one registered value, the redirect_uri query parameter may be omitted from the request.
This mechanism secures against phishing attacks where an attacker phishes the user in to clicking a link that contains a crafted redirect_uri parameter that points to a domain/server that the attacker controls.
The spec allows indeed for registration of a pattern that can be used to match against the redirect_uri value in the request, so e.g. a domain wide policy can be configured. This is an option that is implementation specific. Note that in that case you need to be sure that all possible URLs/paths on the domain are in fact controlled by the client owner and noone else (e.g. that excludes pages that load content from foreign domains, or potential dangerous wiki/forum pages). Since that is pretty hard in real life, the recommended/default matching is very strict.
I am trying to configure a LinkedIn application for a multi tenant site. I will have 20+ tenants using the same application and the number is going to increase every time.
As per Linkedin API documentation (https://developer.linkedin.com/docs/oauth2) we need to ensure following points
We strongly recommend using HTTPS whenever possible
URLs must be
absolute (e.g. "https://example.com/auth/callback", not
"/auth/callback")
URL arguments are ignored (i.e.
https://example.com/?id=1 is the same as https://example.com/)
URLs
cannot include #'s (i.e.
"https://example.com/auth/callback#linkedin" is invalid)
Can i configure redirect url as https://*.mysite.com/auth/linkedin/callback instead of specifying url of each tenant separately.
You cannot do a subdomain based wild card mapping as the IP should know the RP.
You can change the logic after you get the authorization callback, so you set the cookie and then you will have to redirect the user back to the tenant URL instead of the base URL.
Anyway, after successful authorization, you will be redirecting the user to an action, just figure out the subdomaina and the construct the URL and do the redirection
HTH
EDIT
Since the use of the URL or other approaches seem to be a hack, can you please try to have a facade like application (or Gateway like one) that has a URL that is registered in linkedin and then on receiving the response, it can use a state or other factor to redirect to the tenant URL. This can use a 302 and it will be invisible unless the user is on a very slow network. This approach does not require any hack like approach.
Here state can be a function that takes a tenant info and generates a dynamic hash that is stored for tracking and redirection.
We integrate with YAMMER using OAuth2.0 Server-side flow.
Some of our clients have subdomains so our redirect URI has to be dynamic. We set up the yammer-app to have a dynamic redirect URI as specified in the documentation. Our redirect URI looks like this:
https://example.com
Problem:
It works not every time! Some redirects to the YAMMER user authentication page are getting this error:
invalid redirect_uri
The URL looks like this:
https://www.yammer.com/dialog/oauth?client_id=XXX&redirect_uri=http://www.examle.com/yammer/callback
The error only happens some times so it is hard to reproduce or trace the reason.
I tried to remove the redirect url form the app setup on YAMMER. The error still occurs!
Does anybody encountered this problem as well?
What could we do wrong?
Appreciate your help!
I found the solution. According to the documentation my first approach was correct. To use a dynamic redirect URL input the domain like this:
https://example.com
You can try to redirect to the default (http://yammer.com/). In the past you didn't need this parameter and it would always redirect to http://yammer.com.
See these out-dated docs:
https://developer.yammer.com/oauth2-quickstart/