How to Configure AWS Congnito with WordPress using OpenID Connect - Generic Client plugin?

[backpackingseries]

The basic guide erroneously posted here has moved to the Wiki section. Link below -

https://github.com/oidc-wp/openid-connect-generic/wiki/How-to-Configure-AWS-Cognito-with-WordPress-using-OpenID-Connect---Generic-Client-plugin%3F

[timnolte]

@backpackingseries can you please put these sort of things into the Discussions and not open up Issues? It makes it very hard to keep things that are actual issues to be fixed clear. Also you could have also made a PR to update the Wiki page that already exists for these institutions.

[backpackingseries]

@timnolte Apologies. I'm not familiar with Github at all but I'll move it there now. Thanks for the tip.

[timnolte]

@backpackingseries here is the Wiki page for these instructions: https://github.com/oidc-wp/openid-connect-generic/wiki/Identity-Provider-Configuration:-Amazon-Cognito

[backpackingseries]

@timnolte thanks much. done. Will delete it from here if it allows me to do so.

[timnolte]

@backpackingseries I see that you created a whole new Wiki page for this when I said that there was an existing page where this content should go here: https://github.com/oidc-wp/openid-connect-generic/wiki/Identity-Provider-Configuration:-Amazon-Cognito

Also please update your guide formatting to follow one of our existing guides: https://github.com/oidc-wp/openid-connect-generic/wiki/Identity-Provider-Configuration:-Keycloak

[timnolte]

I didn't say it explicitly but please move the content of your new page to the existing page.

[timnolte]

@backpackingseries disregard, I'll move this and clean this up. I didn't realize to begin with that the Wiki was wide open for anyone to edit with reviews. If you want to make these changes then you can open up a PR with the changes, otherwise I'll fix this myself. Thanks.

[backpackingseries]

@timnolte Apologies. I am mess with Github at the moment. I will try to follow along henceforth. Appreciate your support on this one.

[backpackingseries]

@timnolte Lest I'm misunderstood, I'm happy to clean up. It'll take time.

However, at this time, I do not know what a pull request is and how to create one.

I wanted to contribute and so drafted this from my experience so others can use it. I did not mean to add to your or anyone's administrative efforts.

Inadvertently, I managed to do so. I'm afraid I might add to the mess while dealing with it /\

Kind regards,

[timnolte]

@backpackingseries yeah, that's totally understandable. My initial concern was that people might assume that the guide in the Wiki was written by one of us maintainers and we'll need to support it, however we haven't had a chance to review it.

I honestly didn't realize that the Wiki was open to the public for changes without any review process. This can be a challenge to balance sometimes because we welcome contributions but also have to figure out how to manage the contributions.

Anyways, I'll take a look at things tonight as I should have some free time to get things in better shape. I had actually gone through the whole process of setting up AWS Cognito and configuring and testing it out but I just have not gotten around to getting that one documented. Thanks for helping to push that along!

[timnolte]

@backpackingseries just a heads up that I moved your steps into the other location we had with some small formatting adjustments however, I'm going to probably need to revamp these quite a bit as there should be clear instructions to be leveraging the well known OIDC configuration endpoint for all of the details to fill in. Additionally it seems as though your steps regarding generating and using the Client Secret are incomplete and/or incorrect as I'm pretty sure that wasn't my experience when I setup my Cognito instance last year. That being said, all of these IDP configurations can be a complicated thing to tackle as every IDP has their own unique take on how they have implemented the OpenID Connect setup and have very different setups and/or options. Thanks again!

[backpackingseries]

Thanks @timnolte

This is what I found on AWS Docs about client secret:

Public client A public client runs in a browser or on a mobile device. Because it does not have trusted server-side resources, it does not have a client secret.

Confidential client A confidential client has server-side resources that can be trusted with a client secret for unauthenticated API operations. The app might run as a daemon or shell script on your backend server.

Unline Auth0, AWS Cognito does not allow rotating client secrets. I guess it is because their use of Client Secrets is more for internal resources classified as Confidential client. Public clients on AWS Cognito do not require such keys.

Kind regards,

[backpackingseries]

PS: it also states that

An app is an entity within a user pool that has permission to call unauthenticated API operations. Unauthenticated API operations are those that do not have an authenticated user. Examples include operations to register, sign in, and handle forgotten passwords. To call these API operations, you need an app client ID and an optional client secret.

In your plugin, if I do not specify a client secret, the workflow fails. Hence I followed the instruction to generate and provide a random key there.

If I may have misunderstood, happy to stand corrected.

Kind regards

[timnolte]

@backpackingseries so this may be a matter of terminology & configuration differences between IDPs. My main point is that, with the OIDC specs, when setting up a client connection have a Client Secret is required. When I've setup every other IDP that I've tested, Google Workspace/Azure AD/Keycloak/Oracle IDCS, the IDP either generated the Client Secret or provided the option to set your own. With the instructions you've provided I'm not seeing where that Client Secret was configured in Amazon Cognito. Having no secret is somewhat of a security risk configured in the IDP.

[backpackingseries]

Thanks @timnolte

Besides Cognito now, I am only familiar with Auth0 but I think you are right about the differences in terms across the IDPs.

A client secret seems to be more of a machine to machine communication element. There's a relevant discussion on Stackoverflow about it and why it is not considered a security risk for public apps (which is the case for WordPress sites in our case). Quoting the most popular answer here for you please:

It is something like a password. As for why it is used, this is not a Cognito specific property but a part of the OAuth2 standard. Indeed, using app secret in public apps running on browsers makes no sense. In general, when developing a public app, client secret is not used. If you do, you are responsible for securely storing it.

Coming to Cognito, like you said, its JS SDK does not use client secret (as it should be). However, if you use AWS CLI or boto3, you can use client secret. In this case, if your app client has a secret, you are supposed to calculate a hash using this secret and some other parameters (username + clientid I think) and pass it as a parameter.

But in terms of security, it does not really make a difference.

So I can imagine you have included a Client Secret field in your plugin as a OAuth requirement and not necessarily as an IDP thing.

Kind regards,

[timnolte]

So that discussion is not quite accurate. There is indeed machine-to-machine communication going on. There is a whole process while you are already authenticated where the WordPress site communicates with the IDP for user information access, token validation, and refreshing the token. To say that there is no point in having a Client Secret for a website is simply not true.

[backpackingseries]

Yes, I agree. And as is pointed in your plugin (underlined tips), in this case, Client Secret can be an arbitrary string. So that is how I correlated things here:

All said, I am no expert. Only somewhat familiar with the overall approach and happy to be corrected.

Kind regards,

[backpackingseries]

PS: In other words, in this case, the client secret need not be something generated and coming from the IDP into the plugin. Could it that the IDP uses the secret key supplied by plugin, creates a hash, and does the exchange of tokens etc. Would that be possibility here?

[timnolte]

I get overly sensitive about some of these things given the fact that this is pretty much a security plugin. I don't want myself or the plugin to be responsible for a security breach of any sort. This means I will resist more relaxed setups of the plugins with a lot of pushback.

[backpackingseries]

I completely agree with you and, if my setup seems vulnerable, I would like to correct it please.

Also, I do not think the plugin allows for a relaxed config. For instance, if I do not provide a random client secret key inside the plugin configuration, the communication fails. What I am trying to wrap my head around from this discussion is whether this secret needs to be coming from the IDP or can it be a random key as stated in the plugin. I also followed the previous guide on Medium listed on your Wiki. That too goes without a secret key generation on AWS. It says:

Do not select “Generate client secret”. This example will use a public client (ie, no client secret).

Since I share these concerns with you about a missing client secret, I went against the old Medium guide, but during my limited tests, I could not get AWS integration to work for me when I was generating the client secret on Cognito. Hence, I have tried the second idea that your plugin suggests and its working well. All said, if my setup seems vulnerable, I would like to correct it please.

Kind regards,

[backpackingseries]

PS: my setup is somewhat more restrictive as compared with the previous Medium guide. For instance, I do not grant access to the Cognito User Pool API and therefore exclude aws.cognito.signin.user.admin from the scope. I just wanted to create a minimalist / the most restrictive setup for what the plugin can access and manage on Cognito.

[yogeshbeniwal]

Can remove ALLOW_USER_SRP_AUTH and keep only ALLOW_REFRESH_TOKEN_AUTH

[backpackingseries]

@yogeshbeniwal thanks much.

Just tested it and the workflows of registration, login, and logout look good.

Kind regards,