OAuth2 integration with wso2is-5.5.0 adn OWSM - oauth-2.0

I have integrated wso2is-5.5.0 and weblogic12c(OWSM) with our product for OAuth2 implementation.
Imported wso2carbon certificate in weblogic12c(OWSM) key store for token decryption.
Facing same issue, can anyone please provide information about following question:
How wso2is-5.5.0 encrypt OAuth token? From which key? what is key location path?
I am not able to see correct kid values in our OAuth token generated form wso2is-5.5.0. Because key alias is wso2carbon and token has kid NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ.
Do I have to use custom certificate and key alias? Can you please provide document/link to follow steps?
Is there any way to use custom OAuth Client Key and OAuth Client Secret?

Answering your questions,
If you have enabled the JWT encryption, it is encrypted with the key you have configured in the service provider.
In the IS implementation thumbprint of the certificate is used for kid value.
To encrypt the JWT, you always have to upload the public cert to the service provider config. Otherwise you can't encrypt the JWT. So always you are using a custom certificate. Refer this doc to get more details on how to add cert to service provider config.
This is possible if you are adding the service provider from the admin service. Refer to this doc for more information.
Apart from the above questions, if you are signing the JWT, it is signed using the server private key (for super tenant. In case of tenant, tenant private key is used). Default keystore wso2carbon.jks is location in <IS_HOME>/repository/resources/security. You must change this keystore when you do the deployment in production. Refer this and this to change the keystore.
Hope all of your questions are answered.

Related

Certificates for Oauth2 Private key client credentials

I have an application that offers SSO log in through OAuth 2.0 for my customers.
So far, I am using Shared secret client credential, but I now want to support Private key client credentials, and am struggling on finding information on an important detail for the certificate approach:
What type of certificate should be used ?
Does the application have to generate a certificate per customer ?
Is a cloud provider (i.e. AWS ACM) public certificate enough for this kind of implementation ?
For information, one of the systems I have to integrate with runs on Azure. Here is a link to the docs about authentication with certificate credentials

JWK management in openID Connect provider server

I want to implement an OpenID Connect server, I don't know how should I manage JWK for clients? just a single JWK to sing all JWT tokens or generate JWK per client?
I appreciate any tutorial link to help me.
Each client should have their own JWK. OpenID Connect Dynamic Client Registration 1.0 defines jwks and jwks_ur as client metadata.
Ok, I researched about it and what I got is this:
Google uses a single endpoint to get its JWK and verify signatures. no matter for what clients.
Auth0 uses a single private key per tenant, so it uses a single public/private key for all clients in that tenant.
Keycloak uses a single key per realm. so all clients in that realm use that single public key.
My Conclusion
If our OP is multi-tenant, public/private keys can be unique per tenant, otherwise uses a single public/private key pair for all clients. Please note we should have key rotation also.

Let Apigee do authentication (oauth) for client

I have a service protected with OAuth. For it to use, you first require a token.
I have an app, that has only access to an Apigee proxy. I would like Apigee to do the authentication for the client (app), and setup protection with an API key for the client in Apigee. How do I do that?
I think what you are trying to do is what Apigee refers to as Last Mile Security. Unfortunately, it's not as simple as adding a policy and configuring it with a token URL, client ID, and secret. You'll want to make sure you securely store the credentials, cache the token appropriately, and pass the token on to the proxy target.
Fortunately for you, Apigee has a demo project that does what I believe you are trying to do. Basically, your proxy will be configured with simply the Verify API Key Policy (Do this first as if the api key isn't correct, no need to do all the OAuth handshaking). Once confirmed, you can use Javascript policies to check the cache for a token, and then call the OAuth token endpoint to get one if there is a cache miss. I believe it then uses the AssignMessage policy to set the Authorization header to the token. (Note that the example project does not include the Verify API Key policy, but that should be easy enough to add)
Additionally, the demo project stores the client ID and secret in a js file, which I would not recommend. Maybe store it in an encrypted KVM entries?
The Outbound OAuth sample project can be found here.
please refer to below videos for using oauth authentication in your API proxies:
https://www.youtube.com/watch?v=zn94GhcdgHc&list=PLsWqc60hQz4clQ4ykjCu4qyEhdKe11Lvy
You can use Ouath2 - client credential grant Type, that implies that you must add and configure security policies in your proxy, check the following link that explains this flow.
https://docs.apigee.com/api-platform/security/oauth/oauth-20-client-credentials-grant-type

Certificates for authentication and signing

I have a client server scenario.
I have both thick client and a thin client (browser) which communicates with my server.
My thick client uses X-509 system certificate for client certificate authentication scenario and communicates with the server
Also this certificate is used for used to generate signed URL (with expiration time) for my thin client to communicate with my server which is used for integrity and authorization purpose. I also have a token based approach for authentication purpose in this case.
Now i want to complete move my authentication mechanism to OAuth based flow using client credentials or auth code based.
I understand that authentication and authorization can be moved to OAuth based communication. But how do i move my signing (digital signature) based use case to OAuth from certificate based ?
I don't think there is any other way than to use certificate based PKI mechanism for digital signing. Can the private and public keys be distributed other than the certificates ?
Best Regards,
Saurav
Can the private and public keys be distributed other than the certificates ?
You may generate key pair using openssl (command line - openssl.exe) or any cryptographic library or CSP of crypto device. Instead of distributing it, you may have a piece of software which user may use at his end to generate public key and private key and share public key if required and store private key securely. But question remains how user would store private key securely and there comes certificate storage formats like PFX which is password protected (encrypted using password you provide) or storing private key in smartcard or usb token which are cryptographic devices. You may program these devices to generate our own keys and not necessarily store certificate issued by CA.
For browser based access to user's private key, you may need to use browser extension.
Refer to this SO answer for accessing user's keys from browser for authentication.

Why there are primary and secondary certificates for JWT verification in light-4j

When enabling light-4j security, there are two files that need to be in the config folder for JWT verification. primary.crt and secondary.crt. I am wondering why there are two certificates for JWT verification.
primary and secondary certificates are for OAuth 2.0 JWT verification. And these certification supposed to be rotated based on the time or number of tokens signed. Once the new certificate is used on OAuth 2.0 provider, all new tokens will be signed by the new certificate which is indicated in the JWT header kid field. However, there are old tokens signed by the previous certificate still valid and cached on the clients and can be sent to the service. That is why we have two certificates during the transition period. After 15 minutes (configurable on the OAuth 2.0 provider), all old tokens are expired, the old certificate can be removed from the configuration but it won't hurt to leave there. If you are using light-oauth2 as your OAuth 2.0 provider, you don't need to keep these certificates in your configuration as services can call the light-oauth2 key distribution service to get the public key certificate the first time it receives a token. More details can be found at https://www.networknt.com/concern/security/

Resources