Is the format that is used for Ethereum key (ECDSA whatever) compatible with the W3C Web Auth standard.
My understanding is that WebAuthN generates a new set of PKI credentials for each relying party, so the standard does not natively support authentication with a preloaded key (Ethereum key) across relying parties.
Related
We are trying to Sign In the user using OpenID Connect provider - using Code Flow (works fine with implict flow). Issue we are experiencing is that our OIDC provider requires private_key_jwt auth metod to be used.
Only option on Identity Platform when we create custom OpenID Connect provider is Client Secret. I assume we would need to pass Private Key (as with Apple Provider) instead of Client Secret for this to work? Is that even possible with Identity Platform?
No, In Identity Platform Authentication Using OpenID Connect with Apple is not possible with Private Key for that You have to Generate Client Secret.
The reason why we need to create Client secret(for Apple Provider) is mentioned here in the Article as :
Apple’s support for OAuth2 has a number of differences compared to all
the other social providers. Most providers (Google, Github, Facebook)
generate the client_id and client_secret for you. You just need to
keep them in a secure place on the server. In the Apple process, you
first download a private key, and then generate a client_secret using
that private key. The other difference with Apple is that they don’t
support using localhost as a redirect. In the end, I initiate the
OAuth2 process on the Flutter client; but all the redirects and the
token exchange process happen on the server.
In order to generate the client secret, You can follow the steps mentioned in the Article.
For more information, you can refer to the Answer on how to generate client secrets on Apple Platform.
Does Spring Security OIDC client support automatic JWK key rotation? If yes how to configure refresh frequency?
The documentation states that "As the authorization server makes available new keys, Spring Security will automatically rotate the keys used to validate the JWT tokens.", but it doesn't provide information on how to configure refresh frequency.
Yes, Spring Security supports automatic JWK key rotation for OIDC clients. The functionality is contained in RemoteJWKSet (view source). Javadoc states:
Remote JSON Web Key (JWK) source specified by a JWK set URL. The
retrieved JWK set is cached to minimise network calls. The cache is
updated whenever the key selector tries to get a key with an unknown
ID.
Configuring the refresh frequency has already been discussed in 60409678.
One question I’ve had recently about how the JWT middleware in asp.net core works is related to the Authority URL you can set if you want to verify tokens using an identity providers asymmetric keys (JWKS based presumably). All examples I’ve seen completely fail to explain what this authority URL should be. Some auth0 examples say it’s just your auth0 domain - but if that’s the case then how does the middleware locate the public key from this base URL? Every provider has a different convention for the endpoint where a JWKS can be found - so how does this work?
My requirement is that I need to use a home grown identity provider where the JWKS endpoint is totally different to auth0, okla, identity 4 or whatever other providers are using.
Is there some standard discovery mechanism that all these providers use that I’m not aware of? Do I need to have this same discovery mechanism in place I’m the in house identity web app for this middleware to work?
Thanks!
Generally, OpenID connects provider follows the standard and provides a discovery endpoint which includes all necessary endpoints and public key location information.
OpenID connect specification: https://openid.net/specs/openid-connect-discovery-1_0.html
Auth0 exposes OIDC discovery documents (https://YOUR_DOMAIN/.well-known/openid-configuration). These can be used to automatically configure applications.
https://auth0.com/docs/protocols/oidc/openid-connect-discovery
IdentityServer 4 allows to include extra endpoint to the discovery document. http://docs.identityserver.io/en/latest/topics/discovery.html
I'm developing an ASP.Net Core web application and will be using Auth0 for user authentication.
I'm having a hard time figuring out if my JSON Web Token Signature Algorithm should be RS256 or HS256.
From the information that I have found, I still can't make heads or tails of it. Any ideas?
Even though both algorithms make use of SHA-256, they are fundamentally different:
RS256 (RSASSA-PKCS1-v1_5 using SHA-256) relies on generating a digital signature with a specific private key.
HS256 (HMAC using SHA-256) relies on a shared secret plus the cryptographic hash function (SHA-256) to generate a message authentication code (MAC).
Validating tokens issued with each of the previous algorithms implies that for RS256 the entity doing the validation knows the public key associated with the private key used for signing, while for HS256 it implies that the entity knows the shared secret.
Choosing between one versus the other is then usually motivated by the characteristics of the applications that will validate the issued tokens.
If you want to validate a token on a browser-based application, the use of HS256 is automatically ruled out because that would imply you would have to include the shared secret in a place anyone would have access, making it completely useless because now anyone with access to the code could issue their own signed tokens.
In conclusion, if token validation is done on a controlled environment (server-side) you may go with HS256 because it's simpler to get started. However, if token validation is done on hostile environment you need to go with an algorithm based on asymmetric cryptography; in this case that would be RS256.
For our portal development, we have decided to use Apigee to expose the web service to the portal. For which currently I am storing the API Key and Api URL in the properties file of the project. Can anyone help with some pointers on how else can I save the API key apart from the properties file.
Any pointers will be helpful in this case.
Regards
Aswathy
Typically the API key will be persisted by the the API consumer - usually an App of some kind. In case of Mobile Apps, each of them have an API Key or Client ID that is saved inside the app usually in some kind of secure data store. For other kinds of API consumers such as web apps the API Key may be persisted within a secure vault or an database that has some encryption features.
I assume your web portal app resides on a secure machine inside your enterprise and that this machine is access restricted. If this is the case bare minimum security is taken care of
However, If the key is a high privilege key and you can access APIs with key alone(ie without a secret), it is not advisable to keep it in plain text.
You can
1. Encrypt and store it in the config file and decrypt at runtime
2. Encrypt and store in Database or other secure storage you use for storing credentials.