I am trying to add a cognito auhtentification to my load balancer following https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html?icmpid=docs_elbv2_console.
When I setup the authentification process, I have only the "oidc" type, but I expect a "cognito" type :
When I try the rest api, I have the same problem
Action type 'authenticate-cognito' must be one of 'redirect,fixed-response,forward,authenticate-oidc'
cognito is not available.
Am i missing some permissions ? I am an AmazonCognitoPowerUser
I had the exact same issue on region eu-west-3 and it's probably a bug at Amazon that costed me a day of my life.
Good thing is you can actually configure Authenticate OIDC to behave exactly like Authenticate Cognito:
Issuer: https://cognito-idp.eu-west-3.amazonaws.com/[pool-id] (make sure to use pool-id and not pool-name)
Authorization endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/authorize
Token endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/token
User info endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/userInfo
The other info to fill should be straightforward.
Make sure to select your scope(s) in the advanced settings and to allow HTTPS outbound traffic on your load balancer security group.
The Callback URL of your App client in Cognito should be:
https://[CNAME]/oauth2/idpresponse if using a custom domain to access your final app
https://[DNS]/oauth2/idpresponse if using the load balancer DNS name to access your final app
I had the same issue, I was on eu-west-3,
By switching in eu-west-1 or us-east it works perfectly,
I guess the option isn't fully deployed yet
Related
I'm building a webapp with the Google Script engine. Te application uses the Sign in With Google button to log in, so I need a project with a Credential in the Google Cloud Platform which asks me to introduce a domain in the Authorized JavaScript Origin field. Domains of the kind xxx.googleusercontent.com used to work but now they appear to be forbidden.
Google Cloud Platform Credentials
Since the app is hosted by Google Script platform, I've tried the URI https://script.google.com, but it does not work. It keeps on saying:
Not a valid origin for the client: https://n-lvkfgw4qjsttvut5eeun3inieub2bbse7ukpiti-0lu-script.googleusercontent.com has not been registered for client ID 577491057122-qlfn0853m85t0u7gsd4rr69rulghts54.apps.googleusercontent.com. Please go to https://console.developers.google.com/ and register this origin for your project's client ID."
error: "idpiframe_initialization_failed"
Does anybody know anything about this issue?
Answer:
There was a discussion about this on a bug reported on Google's Issue Tracker - this has become disallowed due to security concerns. There is, therefore, no current way to use an Apps Script Web App as a JavaScript origin at all.
More Information:
The bug report in question:
Fail to Add *.googleusercontent.com into Authorized JavaScript origins
An investigation was conducted as there was seemingly no public information about the change. On March 31st 2021, a Googler eventually responded, explaining the reason for the change and closed the issue as intended behaviour:
Current policies for use of OAuth 2.0 require apps to use secure JavaScript origins and redirects on domains that you own. While the use of certain shared domains is allowed (e.g. Firebase apps running on *.web.app), the use of *.googleusercontent.com as OAuth origins or redirect URIs is blocked in order to ensure the security and privacy of user accounts.
Documentation has been updated at Redirect URI validation rules and JavaScript origin validation rules has been updated in order to reflect this:
Host domains cannot be “googleusercontent.com”.
I have kind a puzzle-headed task and i don't know where should i start.
We have a web app that is in our local net. We want to give access to this
app from the outside using apache.
Basically we want pre-login page on apache that will send user credential using api to our app and receive answer with OTP, which user can write in pre-login page inputbox, send again and in case off success apache will redirect user to standard apps login page.
Can apache do that?
Sort of: you can put an authenticating proxy in front of your app that will propagate the established user identity to the backend. See e.g.: https://github.com/zmartzone/mod_auth_openidc
I've got Azure ServiceFabric web-app (AspNetCore 3) hosted over reverse proxy (NGinx). The app use AzureAD (in company) authentication. I've Registered App for the AD and setup Redirect Urls. After publishing the APP and configuring DNS and reverse proxy I tried to authorize to my app but failed with error
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: '...-...-...-...-...'.
I snifed the request and found that it redirects to the internal IP but not domain name
https://login.microsoftonline.com/aeb55839-c47b-4fea-8d95-912f673fa7ac/oauth2/v2.0/authorize?client_id=.....&redirect_uri=http%3A%2F%2F10.2.0.5%3A44321%2Fsignin-oidc...
It seems that I've looked everywhere but I cannot stil found where I can specify redirect url manually (only CallbackPath).
Does anyone solve the issue?
Update 1.
Add screenshot from Azure Portal
Update 2
Mannually add http://10.2.0.5:44321/signin-oidc to the Redirect Url, get a new exception
AADSTS500117: The reply uri specified in the request isn't using a secure scheme.
I wonder whether I have to make my ASF cluster secured to allow AD Authorization? It seems to me strange due to I want to secure traffic to reverse proxy only.
This error will occur when there is a mismatch of redirect URI being sent in the request to AAD while fetching the token and the one registered with the Application Registration Object in AAD portal.
In App Registration blade of AAD and look for the redirect URI section present under "Authentication" section of the registered application and update the redirection
URL. Please refer to the screenshot below:
update:-
The Reply url you are using in your code is http://10.2.0.5:44321/signin-oidc which is different from reply url defined in Azure AD i.e., https://dev-adm.project-llc.ru/signin-oidc. Please update the reply url in code or in AAD.
I have deployed the OIDC provider-keycloak in a k8s cluster and it is exposed as a load balancer.
I'm using this along with Istio to redirect back to my application after successful login in keycloak.
The application is accessible at https://<istio-ingressgateway-ip>/hello
When I hit https://<istio-ingressgateway-ip>/hello, it is correctly re-directing me to Keycloak login page at https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
However, after entering the username and password for the user, I'm not able to get the redirection back to my application at https://<istio-ingressgateway-ip>/hello.
I think the user set up is correct as I'm successfully able to login to the keycloak user console at
http://<keycloak-ip>/auth/realms/<realm-name>/account
I have configured the below values as the 'valid redirect URIs' in keycloak client:
https://<istio-ingressgateway-ip>
https://<istio-ingressgateway-ip>/hello/oauth/callback
https://<istio-ingressgateway-ip>/*
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth/oauth/callback
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
Can please someone let me know what is missing here for the redirection.
Assuming you are using Authservice for the authentication and that your configuration is correct. I had the same issue and when I looked at the logs from the authservice container in my pod, I got to know that authservice failed to obtain the access token in exchange with the authorization code. The issue, as stated by Ryan from Authservice was:
When the Authservice tried to gracefully shutdown the TLS connection, and the server on the other side did not participate fully in the graceful shutdown.
This issue now has been fixed, and you can build a new docker image from the master branch to be able to fix it. More details about the issue and its resolution can be found on this github issue.
If in case this is not the issue, then there could be a problem with the flow from keycloak, you can use OpenID debugger to get the authorization code and then you can use that code to get the access token. This will help you identify if there is an issue on keycloak part.
If your configurations are correct and the above fix doesn't solve your issue, you should consider creating an issue on github with the logs from your authservice container.
when going to the custom AWS Cognito UI Page:
https://<your_domain>/login?response_type=code&client_id=<your_app_client_id>
am getting the following error:
An error was encountered with the requested page.
View error
invalid_request
O-Auth options need to be check as shown in the following picture
from https://aws.amazon.com/blogs/aws/launch-amazon-cognito-user-pools-general-availability-app-integration-and-federation/
You need the following in the App client Settings of your user pool:
Enable Cognito User Pool as "Identity Provider".
Allowed "OAuth Scopes" should have openid enabled.
In my case, it appears there was some issue with verifying the phone number. So switched back to email.
This document is good for checking everything.
https://aws.amazon.com/blogs/aws/launch-amazon-cognito-user-pools-general-availability-app-integration-and-federation/
Unless the SMS Sending setup is not complete, do not choose the Email or Phone option. Email or phone actually falls back to phone number only. Read the warning messages.
TLDR: If you use an AWS User Pool with Cognito App Client and have an Application Load Balancer that is exposed via a custom DNS entry (e.g. custom-domain.com, which has to be secured via SSL), use this custom domain for the Cognito App Client's callback URL (i.e. https://custom-domain.com/oauth2/idpresponse) instead if the random DNS name created by AWS.
I had the same error and this issue solved it for me. I used a User Pool with a Cognito App Client and as callback URL I first used the DNS name that AWS created for it (<load balancer name>-<random number>.<region>.elb.amazonaws.com, i.e. "callbackUrl": "https://<load balancer name>-<random number>.<region>.elb.amazonaws.com/oauth2/idpresponse). I also created a DNS record for a custom domain to expose the load balancer to the internet and secured it via SSL. As a result, the certificate was not valid for the URL created by AWS, but only my custom domain. The Cognito App Client was thus trying to access the URL with the invalid SSL certificate and returned the error.