I am looking into creating a desktop app in an interpreted language that accesses Google's APIs. From what I can tell, there is a security hole. The client secret would be exposed within the code, and even if I created the application in C++ or Java, the code could be decompiled\disassembled and the secret could in theory be found. Is there anyway around that besides obfuscating the code? I'd like to be able to distribute the code for others to use.
OAuth 2.0 Threat Model and Security Considerations(rfc6819) has listed Obtaining Client Secrets as a threat.
And as Google doc Using OAuth 2.0 for Installed Applications says:
These applications are distributed to individual machines, and it is assumed that these applications cannot keep secrets.
So there are no Client "Secrets" in fact. Trying to obfuscate a secret in installed applications is a futile effort as the secrets can always be recovered using the abundance of reverse-engineering and debugging tools.
Of course, you should do your best to protect secrets but at the end, a highly motivated hacker can always get it in an installed application. So it's the value of the secret vs. difficulty of extraction. The value of the client secret is impersonating the application. It doesn't give any access to user data.
My suggestions:
Just take the risk go ahead and obfuscate it. Or you can
consider using the proxy pattern(move the secret to a web server acting as an API proxy).
Related
I'm looking for an API management system, that will intergrate with Keycloak (Keycloak should provide all of the authentication).
Wicked.io (kong based) looks nice.
I've tried adding oAuth2 as an auth method, but wicked keeps generating its own client ids and secrets.
Is there any way to do this with wicked?
wicked.haufe.io maintainer here.
Combining wicked/Kong with KeyCloak may not be a very good idea. Wicked solves a lot of the problems KeyCloak is intended to solve as well, and the overlap is quite big, e.g. doing identity federation (SAML, OAuth2) to an OAuth2 workflow and all that.
KeyCloak and wicked/Kong follow different principles though; KeyCloak issues tokens which are validated via a KeyCloak library inside your services. This more or less replaces the API Gateway - it's implemented inside your services, based on the KeyCloak library.
wicked/Kong as a contrast is built up differently, where the big differentiator is the API Portal wicked provides on top of Kong and that you have a dedicated API Gateway (Kong). Wicked provides you with its own client credentials, and it also wants to do the entire authentication and authorization bit. What you get in exchange for that is the self service API Portal; if you don't need that, you will probably not need wicked.
What you can do is to federate a KeyCloak OAuth2 flow into wicked, by having KeyCloak act either as a SAML or OAuth2 identity provider. You would then register your KeyCloak Authorization Server as an identity provider with wicked (using a single service provider (SAML) or client (OAuth2)). The "but" here is that you would still need to provide an entry point to your services which do not go via the KeyCloak library.
wicked/Kong always works like this: It takes away the need to implement Authentication/Authorization inside your services; instead you need to check for the headers X-Authenticated-UserId and X-Authenticated-Scope. With wicked, this will typically contain something like sub=<some id>, also depending on which type of identity provider(s) you have configured wicked to use. But this approach usually replaces KeyCloak. The upside is that you can have one single entry point to your services (=Kong), and you have a quite lightweight way how you can protect arbitrary services - not only services written in languages KeyCloak supports! - behind an API Gateway while providing self service access (with configurable plans, documentation,...) via an API Portal.
All these things are obviously somewhat complicated; wicked is extremely flexible in its usage, but it's not really meant to be combined with KeyCloak (which is likewise. It all boils down to really understanding the use case and finding a solution architecture which solves your use case in the best way.
If your use cases involve an API Portal and API documentation (it should), going wicked/Kong may be a good possibility. If it doesn't, you may be happier sticking to KeyCloak (which you can see as a headless API Management system with a decentralized gateway of you want).
Disclaimer: My knowledge on KeyCloak is somewhat outdated; it may be that there are updates which also go into the API Portal direction, but of this I am not aware.
Similar questions have been asked before (1,2), but not explicitly answered:
Is it safe to store the client id and client secret credentials obtained for an Installed application -> Other for the Google API with the distributed source code of a command line application which will be distributed? Or will it be possible to access user accounts or data without the access_token granted by user consent?
The Google API docs specifies that..:
.. results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)
it is apparent from other documentation that this is not best practice: the client_secret should not even be provided by the service, but it is currently required by the oauth2 and googleapiclient libraries (for Python), and probably by the Google service as well.
The application will use oauth2 based on these official examples.
References, good explanation or documentation that confirms whether this is truly safe or not is much appreciated.
Client Id is a publicly visible and it is safe to put it in your website, but it is not safe to put your client secret in js or html code in a website
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'm making a website that I'm planning on making readily deployable by users; they'll be able to take my source code and deploy it to their own server and run it as their own.
I was thinking of trying to incorporate SSL and OpenID and other features into the website. Would giving the users access to these files (such as my OpenID/Twitter/Facebook client key and secret, or the SSL certificate stuff, or whatever else..) be a potential security hazard or anything? Would they be able to do anything dangerous with this information?
SSL is not the app's concern
All client key and secret are your own responsibility... I wouldn't distribute them openly.
Normally what one does is to read this information from the environment
facebook_client_key = ENV["FACEBOOK_CLIENT_KEY"]
so the deployer has only to configure the environment, not the application.
I would steer clear of adding things like your clients keys and secrets to any files you distribute to your users. They're called secrets for a reason! I don't known the ins and outs of Facebook or Twitter's APIs but certainly with products such as Akismet, the anti-spam addon for Wordpress, the key is used to identify your particular Wordpress instance.
If you are using a Wordpress site for commerical purposes, you're supposed to pay for Akismet. The problem is that whilst you might not be using it yourself for commerical purposes, depending on what you're making and distributing that's not to say that other people won't use it for commerical purposes, and end up ruining it not just for you, but for everyone else using your software.
You should make the keys and secrets part of your application's configuration and, perhaps, provide instructions on how your users can obtain their own.
I have an app that uses a single-user OAUTH token. I can store the four values (consumer key/secret, token/secret) directly inside the app but that's not recommended and I don't want the secrets to be checked into source code. The app doesn't use a database. I know that however I store them, someone with access to the server could figure them out but I'd like to at least get it out of the source code. I've thought of passing them as Passenger environment variables or storing them in a separate file on the server but are there better ways? Is there any point to encrypting them since anyone that could see them would also have the access needed to decrypt?
Not having the keys stored in the source code actually is actually bad a practice in the accoding to the most agile setup (continuous deployment).
But, by what you say, you want to have two groups: those who can make the code, and those who can deploy it. Those who can deploy it have access to the keys, and, in the most secure setting, must NOT use the code of the application. You can make the oauth still work by having those who code autenticate to a system that proxies all the authorization part, and authenticates de application. Such keys (app -> auth middle man) can be in repository, as they are internal.
Any other setup: authentication library created by those who can deploy, encrypted keys, anything else can be broken by those who make the code. If you don't trust them enough to have access to the keys, you probably don't trust them enough not to try to jailbreak the keys.
The resulting deployment scheme is much more complicated, and, therefore much more prone to erros. But it is, otherwise, more secure. You still have to trust someone, like those who install the operating system, the proxy's system middleware, those who maintain the proxy's machine(s), those who can long on it, and so on. If the groupo of people with access to the keys is small enough, and you trust them, then you've gained security. Otherwise, you lost security, ability to respond to change, and wasted a lot of people's time.
Unfortunately, all authorization schemes require you to trust someone. No way around it. This is valid for any application/framework/authorization scheme, not only sinatra, rails, oauth, java, rsa signatures, elliptic curves, and so on.