when i use local validation instead of introspection in my project with OpenIddict
usually the Authserver and the Resourceserver are sharing one symmetric encryptionkey. However when i use more than one Resourceserver i would like to use more than one symmetric encryptionkey (each Resourceserver should have it's own encryptionkey). Is there any way to achieve this?
Thanks for your help,
Nicolai
This is not currently supported.
It may be supported in a future version, but it has important design considerations: e.g the JWT compact format doesn't support embedding multiple content encryption keys, which prevents issuing encrypted JWTs to different recipients/resource servers.
If you don't want to share the secret with the resource servers (e.g. if you need to support 3rd party resource servers) you can use introspection.
But introspection has another drawback: I found no way to cache the introspection response in the openiddict validator. I don't think it is a good idea to have a roundtrip to the auth server on every API request. This could slow down high frequented API servers. Not sure if there is a simple solution for caching the response...
Related
I am very aware that you can't store your secret on a front end app, however, is there any way to work around this thus still having the benefits while using the javascript adapter.
I'm guessing using the JWT token option lead to the same issue.
I've read about using 2 different clients, one as a confidential admin and the other as a public client. All though I don't see how it is any better as the secret will still be held publicly, just in a different location.
Should I look deeper into this, are there any other workaround ?
Thanks
Solution : This won't turn your client into a confidential one, but you can add a layer of security by using PKCE.
I’m developing my own OAuth2 + OpenID Connect implementation. I am a bit confused about how to handle OAuth flows for native (specifically, Mobile) clients. So far, I am seeing that I need to use an Authentication Code Flow. However, based on my research, there are some details that seem to contradict each other(at least based on my current understanding).
First, standard practice seems to say that mobile apps are not inherently private and, as such, standard flows that make use of a back channel should not be used. As a work around, the PKCE extension can be used (and utilize the built-in device browser as opposed to a web view so the tokens and sensitive information are less likely to be leaked).
However, under the Protocol’s Dynamic Client Registration specification, it is also mentioned that mobile apps should use this method of client registration to get a valid client ID and client secret... But, why would we do this when in an earlier section it was established that mobile applications were indeed public clients and couldn’t be trusted with confidential information like a client secret (which we are getting by using this DCR mechanism...
So, what am I not understanding? These two things seem to contradict one another. One claims mobile apps are public shouldn’t be trusted with a secret. Yet, in the recommended DCR mechanism, we assign them the secret we just established they can’t be trusted with.
Thanks.
A bit late, but hope it helps. So part of the OAuth2.0 protocol is two components, the client_id, and client secret. The client and server must agree on those two values outside the protocol i.e. before the protocol start. Usually, the process is as follows. The client communicates with the Authorization Server using an out-of-bound communication channel to get these values and be registered at the server. There is two way this client registration can happen, statically and dynamically. Statically mean the client_id and secret do change, i.e. the client gets them once when he registers with the server. Dynamic client registration refers to the process of registering a client_id every time the client wants to use to protocol, i.e. a client secret will be generated for him every time (also by an outbound communication).
Now, Why use dynamic registration?
Dynamic client registration is better at managing clients across replicated authorization servers., The original OAuth use cases revolved around single-location APIs, such as those from companies providing web services. These APIs require specialized clients to talk to them, and those clients will need to talk to only a single API provider. In these cases, it doesn’t seem unreasonable to expect client developers to put in the effort to register their client with the API, because there’s only one provider.
Does Dynamic Client registration offer any security advantages?
No, both are vulnerable if used with a JavaScript or a Native Mobile Client (JavaScript client can be inspected, and Mobile apps can be decompiled). Hence, both of them require PKCE as an extra layer of security.
We are building our applications in micro-services based architecture to implement our applications. As true with micro-services, we now see a lot of cross service interactions happening between services.
In order to safeguard the endpoints we plan to implement JWT based authentication between such secure exchanges.
There are 2 approaches we see helping us achieve it:
Embed an JWT engine in each application to generate the token (#consumer side) and evaluate (#provider side). With an initial exchange of keys, the token exchange shall work smooth for any future comms.
Have an external (to application) JWT engine, that sits in between all micro-service communications for the distributed application, and takes care of all token life cycle, including its encryption-decryption and validation.
There are lot of options to do it as per option #1 as listed on https://jwt.io but considering the over-head token generation and management adds to a micro-service, we prefer to go with 2nd option by having de-centralised gateway.
After quite some research and looking at various API gateways we have not yet come across a light weight solution/tool that can serve to our need and help us get centralised engine for one applications comprised of many micro-services.
Do anyone know about one such tool/solution?
If you have any other inputs on this approach, please let me know.
I prefer also option 2, but why are you looking for a framework?
The central application should only be responsible of managing the private key and issuing the tokens. Including a framework for solve one service could be excessive
You can also think to implement a validation service, but since applications are yours, I suggest to use an assymetric key and verify the token locally instead of executing remote validation requests to central application. You can provide a simple library to your microservices to download the key and perform the validation. Embed any of the libraries of JWT.io or build It from scratch. Validating a JWT is really simple
If you would need to reject a token before expiration time, for example using a blacklist, then It would be needed a central service. But I do not recommend this scheme because breaks JWT statelessness
Both scenarios could be implemented in Spring Cloud Zuul.
For more info:
http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_router_and_filter_zuul
http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_configuring_authentication_downstream_of_a_zuul_proxy
I want to secure my application with JWT. This application is only accessed by other server applications that know the secret key before hand. I do not need to add a token generation since the key is already known between the applications. I tried to find some samples for this, but all the examples are complicated (I'm new to spring security) and moreover they do not include anything simple that would fit my use case (known secret key and algorithm, so no provider and storing of the token is needed).
Basically what I want is to decode the token sent by the fellow server, check the secret key, check the sender and check the time (the fellow server will always generate a new token so if that token is stollen then it will be invalid in a small amount of time).
I've thought of implementing this with a custom filter (or interceptor) plus this library and remove spring security entirely, since I can't find any use for it. But I would prefer to use spring security in order to have it available for any future needs and in general achieve what I want by doing it the spring way.
The JWTFilter from JHipster may be a good start!
I have developed a 'REST-like' XML API that I wish to expose for consumption by third-party web applications. I'm now looking to implement a security model for the exchange of data between a third-party application and the 'REST-like' XML API. I would appreciate suggestions for a suitable asymmetric encryption model.
If you want encryption why not just use SSL to encrypt the connection rather than encrypting the response data? If 128-bit SSL isn't sufficient, then you'll either need to integrate some existing PKI infrastructure using an external, trusted authority or develop a key distribution/sharing infrastructure yourself and issue your public key and a suitable private key/identifier to your API consumers. Choose one of the cryptography providers in System.Security.Cryptography that supports public/private key exchange.
HTTPS works with asymmetric key encryption. It is well-known protocol easy to implement.
It protects against 3p intrusion in your communication.
All you need to implement "below" is authentication - to make sure your user known to you.
Common thing to do is to provide users with key that needs to be sent with every request.
Most common is to implement the OAuth protocol. This is what is used for the OpenSocial providers that checks authorization with 2-legged and/or 3-legged oAuth
Just do some google search and you will find a lot of implementations.