We received this google warning because one of our google projects has multiple domains.
Your project: {app} has multiple unique domains in the redirect URI and origin URLs, many of which have unrelated applications. This is in direct violation of the Google API Services: User Data Policy, which requires that projects accurately represent their identity and intent to Google and to our users when they request access to Google user data.
The first domain is the website of the app {app}.tld
The second domain is the api where OAuth happens {tenant-id}.subdomain.domain.tld
Our violation comes from the domain {tenant-id}.subdomain.domain.tld which is where we host our multi-tenant api.
Is it possible to resolve this issue while still using our multi-tenant api to handle the OAuth dance?
I Guess you are using the {tenant-id}.subdomain.domain.tld as the callback url and adding a unique url for each tenant.
To solve this issue i think you may add a single callback url. Something like callback.domain.tld may work. This endpoint should redirect the original google redirection to {tenant-id}.subdomain.domain.tld with all the query params from google. You can encode the tid in state so that you can decode it to redirect the request properly in the redirection service.
You can also use some services like AWS lambda to act as the middleman and redirect to your final endpoint.
It's okay with that {tenant-id}.subdomain.domain.tld as the callback URL and adding a unique URL for each tenant.
Related
Whenever we configure Identity Provider in KeyCloak, it automatically sets Redirect URI like
http://keyclaok:8080/auth/realms/{MY_REALM}/broker/google/endpoint
I am implementing multi-tenancy in the project. For every tenant, I will have a separate realm and in turn, have a separate Redirect URI.
For this to work, I need to configure the same URL in "Authorized Redirect URLs" in Google Cloud Platform Console.
To ensure KeyCloak's IDP Redirect URI and Google console's configured Authorized URL match, there are 2 possible options
Dynamically(programmatically) configure Authorized Redirect URL in Google console when new tenant/realm is created. As far as I know, there is no way to dynamically set this authorized redirect URL. So this doesn't look like a viable option.
Configure custom redirect URI in KeyCloak. However, Keycloak doesn't seem to allow changing Redirect URI for Identity Provider.
Any solution, workaround or hints would be appreciated. I feel this is not a unique problem that I am solving. It must be already done and solved by many.
I try to integrate my Python app(backend client) into the Keycloak system using openid connect, why do I have to fill the Valid Redirect URIs field? From my understanding for OAuth 2.0, the backend channel just need to exchange the code for id and access tokens in the Authorization Code Flow process
Why do we need a redirect URL here, shouldn't it only filled in the front end client?
Any Ideas?
We need it to restrict to what URL we are allowed to redirect to after a successful login. We do this to improve the security for your users, because it would be a big security problem if the provider could redirect to any URL after login.
The client which receives the authorization code and the one which exchanges the code for tokens must be the same client - at least from the Authorization Server's point of view. Theoretically you can have separate applications which handle parts of the OAuth flow, but they must be using the same client ID.
Ideally, the redirect URI points to an endpoint exposed by your Python backend. After Keycloak (or any Authorization Server) finishes authentication and authorization, it will redirect the user to that endpoint together with the authorization code. This way the authorization code will go straight to the backend client, the frontend app will never have to handle it. By registering the URL you want to make sure that no one performs authorization using your client ID, but asks to send the code to another application.
I was reading the site Oauth.com trying to understand how implement security in a Single-Page App when i found this statement:
"The only way the authorization code grant with no client secret can be secure is by using the “state” parameter and restricting the redirect URL to trusted clients. Since the secret is not used, there is no way to verify the identity of the client other than by using a registered redirect URL."
If i undestanf correctly, he says that i can verify the identity of my SPA using a registered redirect URL.
Question 1: If I redirect the authorization code to a url (web server), how can i get it (or the access token, or the protected resources) back in my SPA that is running in a browser ?
Question 2: what kind of check can be done in this registered url to verify my SPA identity?
Q1. You receive an authorization code as the login response in a query parameter. Then swap it for an access token. Then call the API with the access token.
Q2. Use HTTPS to prove that you own the redirect URI. Use PKCE to create a one time use secret at runtime.
RESOURCES OF MINE
Maybe these resources will give you a clearer idea - feel free to post any follow up questions ..
SPA Message Workflow
SPA Tutorial + Code Sample
The authorization code is included in the URL as the code query parameter, so you can access it from the SPA (e.g. with window.location.search). It will depend on the OAuth2 provider whether you will be able to exchange that code for an access token from your SPA.
If you use a web server to do the code->token exchange, you'll need to put the tokens in a database that your SPA has access to.
The quote from OAuth.com mentions two security measures, the state parameter, and registered redirect URLs. These prevent two separate attacks:
The state parameter prevents an attacker from using your URL with a stolen authorization code to retrieve an access token for a victim user and associate it with the attacker's account. By verifying that the state parameter in the URL is the same state that you provided to the authorization server, you can be sure that the redirect was generated by the authorization server, and not an attacker.
The registered redirect URL prevents an attacker from using your client ID, but sending users to an authorization URL that, after authorization, will redirect them to the attacker's web server instead of yours, allowing the attacker to retrieve the user's access token. With a registered redirect URL, the authorization server will only redirect to the pre-registered redirect URLs, which you control, and will not redirect to an attacker's web server.
An alternative to implementing this flow yourself, particularly for a SPA, which has limitations in what OAuth grant types are available to it, is to use a managed OAuth service. Xkit, which I work on, is designed to work with SPAs and moves all of the OAuth flow (including security considerations) out of your code.
We have a public API that supports OAuth 2.0 server and client flow. Per OAuth 2.0 spec, https://www.rfc-editor.org/rfc/rfc6749, each integration application will have 1 application key and users using that application will authorize that application for API access of user's data.
Things worked fine until we find application developers suggesting their users to create one application key each as users will all have their own redirect uri. Put aside the false API usage information it creates, we are seeing a big increase in application key creations that is not tolerated by our API agency.
I am wondering if we can suggest such application developers to add an extra layer for redirect between our oauth server and their users' redirect uri. So their application key will be created with a redirect uri that actually loads a page created by their application, then redirects to the user's specific redirect uri, which is inputted at the user's registration.
Hope I explain it well. I am wondering whether this exposes any more security vulnerabilities than it already has. My point is someone has to do the redirect anyways, rather than we do it with all the unnecessary extra information involved, we'd like to let our client applications take control of it.
Any suggestions/hints/clues/ideas are deeply appreciated.
I have a file server, or more of a personal CDN, which I want to protect against unauthorized access. Assuming that this personal CDN is accessible through https://www.personalCDN.com, and the requests to this file server come from the following domains:
1- https://www.Application1.com
2- https://www.Application2.com
3- https://www.WebSite1.com
In case I want the authentication layer to be cookie-based in a way that, when the user logs into any of these three domains, a cookie for https://www.personalCDN.com would be added to browser, and then it would be used by the main file server, how can I handle this situation in ASP.Net Core 2.x? I've read that, writing cookies for other domains is not allowed in JavaScript, does it apply to Asp.Net as well?
It's not a JavaScript limitation, it's a functional limitation, in general. Cookies are domain-bound. They can only be written on the domain where the response originates. Likewise, a cookie can only be read by the domain that set it. This is for security reasons, and there's absolute no way around it.
What you would need is a SSO (single sign on) solution, which is not a trivial thing to set up. You essentially have one server that acts as the auth gateway. Your other websites redirect users to that server to login, the user logs in on the auth gateway, where a cookie is set for that domain (i.e. auth.domain.com). This keeps the user logged in on the gateway. Then, the user is redirected back to the originating site, with a token. That token is then validated via an API backchannel to the auth gateway. If the token is valid, then the originating website "logs in" the user, setting a cookie for its domain, as well. Rinse and repeat with all your other websites.
For something like your CDN, you would likely need a site hosted on a subdomain of that same domain (since the CDN itself wouldn't be able to coordinate the auth process). That site, then, would set a wildcard domain cookie, which would be usable by the CDN as well.
You can either set up all this infrastructure yourself (not recommended), or there's third-party libraries like IdentityServer that could ease implementation. Additionally, you can outsource the whole shebang to a third-party provider like Auth0, where it essentially becomes your gateway.