I am developing software that will be used on small system at clients. The software is fetching Google calendar events from whatever Google account the client adds to it. The thing is that Googles API requires an secret key to work. As it is now, the system is working but the key is directly in the code, which means that the end user will be able to see it.
Firstly, is this a problem? I guess that because the key is "secret", there will be bad if a client can see it. Second, if this is bad, how should I do to avoid this? Is it even possible?
I should not be a problem since the key alone is not enough to generate an access token. You also need a refresh token or authorization code for that.
One risk is that, using the key, one of your clients (Alice) builds an OAuth authorization URL and tricks another of your client (Bob) into authorizing Alice's custom application to get calendar data. That problem only occurs if you're using the "installed application" workflow with the "urn:ietf:wg:oauth:2.0:oob" redirect URI.
If you want to avoid this problem, you can decide to host a web service that will handle the authorization for the embedded system. This web service will hold the client secret, and will receive call from your systems to either request authorization from a customer or refresh a token. Of course now you need to secure this web service, but you can probably do that with a customer-specific set of credentials. That way the only thing on the customer's premises are his specific credentials to access the webservice, nothing else.
Related
I am very new to the concepts of SSO and Keycloak. I am trying to read the official documentation of Keycloak. In the "Supported Protocols" part (https://www.keycloak.org/docs/latest/securing_apps/index.html), the documentation talks about the two use cases of using OIDC like this:
"The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request."
What I do not understand is this: In the first paragraph it talks about an application making a request and in the second one it talks about a client. But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Thank you.
But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Yes exactly it. The reason for the differentiation is because there could be many applications more than just this one client. And the client, that the user is authed against may want to access all those other applications' data.
For example take the google ecosystem. Does google email have access to drive, and photos, etc... While it could out the box, it doesn't. You need to explicitly allow email "offline access" to those other applications, even though they are all part of the same platform.
Keycloak understands this and provides that terminology. But it is a bit confusing because this isn't the best way to think about it. Instead a better explanation is that there is just the user and service clients. The service clients all talk to each other and ask for a user's data. While a user may want their data by going straight to one application, other applications may want that user's data too.
Assuming you want to actually allow one service to ask for user data from another service, you want to be using something that supports authorization as a service and not just authentication. There are some examples of this, such as PolicyServer and Authress.
I have a progressive web application that needs write-access to the Google Drive API for uploading data (media files) the user is creating (either online or offline) in the background while online. It does not really need a server (except for serving the required files, so a static server is sufficient), all of the work could be done on the web application client side.
Since uploading needs to happen on the background, whenever the user is online again (using a service worker and the background sync one-shot API), an access token is not enough for my need (the user can be offline/not use the web application for days) and a refresh token is not supposed to be stored on the web application client side, as far as I understand. Even if it were, I would still need the client secret, which means I have to use a server (or keep the secret within the web application client side, which is a no-no) in order to refresh the token.
It seems like the current ways of using the OAuth2 scheme are at odds with server-less progressive web applications, or I might be missing something. Progressive web applications are more like Chrome applications in this regard, I guess, but I have to supply a Chrome application ID in the Google API console for my application, which I do not (and do not intend to) have and Chrome applications use the Chrome identity API for getting the tokens, which I do not intend to use (and cannot).
I am currently using an actual Node.js server which takes care of the authorization step, keeps the access token and refresh token in a database and returns the existing or new access token to the client, whenever asked. The server is redundant here (and requires a privacy policy for this data which I really do not need to store), I want to do everything using client code, without continuously asking for authorization whenever I upload in the background.
Keeping the refresh token on the web application client side and just reaching out to the server for actually refreshing the access token (nothing must be stored in the server side except the client secret, which is fine), but like I mentioned, I understand the refresh token is not supposed to be kept on the web application side.
Is there a safe and secure way to implement this without a server (or with a server that only gets the refresh token and returns it to the client and refreshes the access token by getting the refresh token from the client)?
It's actually fairly simple, depending on the fine details of your use case.
An important factoid is that once a user has granted permission to your app, he will not have to re-grant it. So you don't need to "continuously asking for authorization whenever I upload in the background". However, the only constraint is that the user must be logged in to Google in order to obtain an Access Token. Normally this isn't an issue, but your app needs to deal with the scenario that a user has logged off from Google, and prompt for login.
All the details are here https://developers.google.com/identity/protocols/OAuth2UserAgent
I suggest avoid the Google JS library because (a) it has its own opinions about the UX, (b) wasn't written with PWAs in mind, (c) has issues on mobile, and (d) is closed source so when it breaks (as it does occasionally), your users are dead in the water until Google fixes it. The page above details the OAuth endpoints so you can easily use them directly. This has the side benefit that adding other cloud storage accounts (AWS, Azure, Drop, etc) is just a case of changing the endpoint URL.
The architecture I use in my PWA is to have my PWA prompt once (and once only) for authorization and then store the user's Gmail address in localStorage. I then have a
hidden iframe which polls once per hour for an Access Token, using the gmail address in a login_hint. This means the iframe is never required to present any UX. The only time UX is required is for the initial auth, which is of course unavoidable, and once per session if the user has logged out of Google.
The only other edge-case you might want to deal with is allowing the user to select between multiple Google accounts, say a personal account and a work domain account.
On a broader point, remember that Google didn't create the OAuth spec so there is little they can do to provide an alternative solution. At an abstract level, auth requires one of the user being present, or secure storage for a permanent token (eg on a server or within a secure store such as Android). Even if we invent OAuth 3, that will still be the case.
I would like to secure my mobile app ( hybrid app, build with ionic framework). On backend site I use the play framework. I would implement the following case. The user of the app should authenticate to rest backend by email and password, if the credentials correct the backend generates an token return ok with the generate token to client, otherwise the backend return bad request. If the user would try to login with incorrect credentials more then 10 times the user would deactivated for 1 hour.
The mobile app would load json data from backend with ajax calls, on each call in header would set the field 'X-AUTH-TOKEN' and the generate token. The backend check the token and if the token is correct the client get data from server with status ok else the client get none data and the status unauthorized. If the user logged out the token would destroyed on server and client side. The token would not change as long as the user is logged in, in worst case the token would not changed over more than many days. I could implement, that on each call the date of last call can saved and if the last call is more than x days in past the server return unauthorized and destroy the token. So the user should logged in. Is the case secure enough, or should I implement more logic?
What you are describing is very similar, if not identical to the many, many implementations of OAuth2. For more information on these types of flows, including diagrams, check out how Google describes their OAuth2 processes here: https://developers.google.com/accounts/docs/OAuth2
I'm not familiar with the play framework but you should speak with framework experts to see if there is a well-tested, battle-hardened oauth2 implementation out there for the Play Framework. If so, you want to use that. You really don't want to (and shouldn't) roll your own implementation unless you know what you're doing and are willing to pay for people to pentest it. Really, please don't do this if unsure.
On the Ionic Framework / Angular / Cordova side, you've basically got it correct, but should always consider some basic security considerations:
My guess is that you'd use local storage to store the access token. In REST we don't have sessions like in a traditional web server scenario so we use the token in lieu of the session. Of course the downside is that local storage can easily be inspected to obtain the access key if someone had either root access on the device and was able to work their way into the app sandbox and knew exactly what api key to grab from local storage, but if someone has root or physical access to the device then you've got a bigger problem, so this isn't a design flaw per-say. To a certain extent, using this method you're relying upon the OS/browser's local storage sandbox to prevent other apps from accessing the local storage in your ionic app. This is a bet I would be willing to make, but you'll need to judge that based on your security vs usability needs.
What you should really be focusing on is protecting the token from people who may be listening on the wire (think coffee shop wifi). This means setting up your auth rest servers to use exclusively HTTPS (don't fail back to HTTP). This may have downsides, but will be worth it to protect your user's data. You also correctly identified using the token header. You should never pass auth tokens in anything but the header or POST data.
Generally speaking, what you are describing should be safe for use in a consumer level app. This assumes you don't unwittingly use any malicious third party code in your app. As always, you should be especially wary of third party code and only use code that you absolutely trust. Any code run from inside your app can access local storage in the Cordova/browser local storage sandbox and could theoretically export the api token for use in other software to access your api. With that said, you asked about authentication and not authorization. Keep in mind that your users need to only have access to do certain things in the app based on user-roles or some sort of ACL. This authorization outside the scope of this answer but you need to ensure that this is done on the server side and has rate limiting or soft-deletes for shared resources to prevent a malicious user from deleting everything.
Good luck with ionic and have fun.
I'm creating a mobile app for customers that need to access an api that I use.
The api requires authentication and the app needs to call the api to receive some data that is specific to each individual customer(mobile app).
I just want to make sure that the right way to do this is for the mobile app to send the query to my server which will then make the authenticated api call and return the response to the mobile client?
or is it possible to have the mobile make the api calls directly, presumably using the same authorisation key?
This is primarily an opinion-based question, however I'll give it a go:
[paraphrased] Can my server act as an API proxy to make authenticated calls to another API on behalf of my unauthenticated users?
This is a common occurrence in the API world, but some things you need to consider:
It's an extra layer in between the user and the service, which adds time to the data transport. Make sure you build your proxy to be scalable or use a 3rd party service that can manage that on your behalf. Either way, don't forget to factor in cost.
Usually service providers require authentication for a reason. Are you violating any license agreements by opening up their API like this?
Is the authentication per-application, or per-user? If it's per-user (e.g. each user logs in and retrieves a unique access_token) then you're going to be making calls to the back-end API as a user instead of an application.
Is the destination API rate-limited? Instagram's API, for example, only allows 5000 requests per hour. If you have 10,000 users that use it once per hour, you'll have already hit that limit.
Are there security concerns opening up the destination API like this? Is there sensitive information that you need to protect? If so, opening it up like you do are you creating security holes?
Is it possible to have the mobile make API calls directly to the target API, presumably using the same authorization key?
Absolutely this is possible - provided that you follow the authentication flow established by the target API. You'll want to consider the same list of concerns listed above though, in addition to:
If you're using an auth flow like OAuth2, the standard dictates that each user should authenticate as themselves and make API calls using a unique access_token. Does your target API provider offer this service? If so, that's the way to go, that way if an access_token is compromised, only that user's data/account/etc. is at risk.
If you're using app-level authentication (e.g. your app's client_id and client_secret) directly in your mobile app, be warned that it can be obtained and compromised with little effort, and thus an attacker could gain access to the entire target API this way.
I'm in the middle of creating a RESTful API for a personal project and I've been reading about api authentication. It is probable that I just don't understand what different things are for. What is OAuth for? What are API keys for?
Main Question
Why can't I just have every request use HTTPS and use sessions/cookies?
If users will access your API through an application you own or control, then HTTPS and user authentication/authorization is ok.
However, if you want to allow applications created by other developers to access your API OAuth and API keys allow you to control how these third party applications use your APIs.
API keys: By assigning individual api keys to each application, you can identify the application sending the request. You can use this information to track or limit what the application can do with your APIs.
OAuth: If the 3rd party application needs to access sensitive data owned by users or perform an operation on their behalf, then you want to ensure the user is ok with this. One way you can do this is to require the application to pass the user credentials with every request. However, this is usually not a good idea as you don't want users to reveal their usernames and passwords to third parties. Here is where OAuth comes to the rescue as it allows users to provide third parties with limited permissions to access your API on their behalf.
SSL is adequate for this if:
you require a client certificate
the application obtains the client certificate
the application validates it against a list of acceptable clients
the application records which client executed the transaction.
Without all that you're just accepting transactions from just anybody, which is the problem that OAuth is solving.