I am building an application that uses OAuth to authenticate and grant account access to users.
The current authentication flow is as follows:
Create new application
Register application with API service
Store granted client ID and client secret securely
Launch application
Application opens service's OAuth request for approval in SFSafariViewController
User approves the application to access their service's account
Callback to application provides code, which is received in AppDelegate
Notification is posted, passing the code to the view controller that will initiate the request to exchange a clientID, client secret, and code for an OAuth token to be used for authenticating subsequent requests
Send request with client ID, client secret, and code to exchange for OAuth token
Store token in Keychain for subsequent API requests
I have everything working as listed, however, I don't know how to store the client ID and client secret that I am granted when registering my application with the service. The client ID and client secret are to be kept securely and not shared. They will be used when a user exchanges them for an OAuth token.
Since I am using GitHub for version control, do I create a property list within my application to store the items? If so, I can just add that file to my .gitignore. Is this an appropriate method for storing my credentials?
You should not store a client secret inside a native app as it is a public client. Native apps are incapable of protecting data from the resource owner (and therefore a client secret).
Client secrets are intended for servers (or any confidential client) that are able to properly hide a client secret. You can standup a server (where the client secret can be stored) that handles the incoming requests from your mobile app over HTTPS, then sends back Access/Refresh tokens to your mobile app.
If I understood your question right (you need to store keys for each user), you may store them in iCloud containers. Basically it's like UserDefaults but in user's iCloud. You may write and read from there. Check out this docs for more info.
Let me know if it helps cuz not sure if I got your question the right way. If not please explain it in other way :) thanks
Related
I am trying to figure out how to perform single sign on with OAUTH2 on two different applications. Currently according to my understanding I can use the Authentication Provider in order to authenticate my clients. The procedure is the following:
The client is redirected to the Authentication Provider
Then the client is loggedin and has the code
The client provides the code to my application
The server uses the code in order to retrieve the access token.
Using the access token my server uses the remote API to retrieve information
Now I have a second application in a different backend (PHP) that I want to inform that the user is already loged in via the OAUTH. My naive solution is to provide the access token of the first application to the second application in order to perform the authentication. However, I understand that I am not allowed to share the access tokens between apps.
Every backend service should validate the access token via introspection. The only introspection guarantees that the token is valid, not expired or revoked.
So you have to pass the access token to the Backend service. To secure that you can use HTTPS API.
You are correct regarding not sharing the access token. The Authentication Provider should also allow creating an ID token. You would configure your second application with the authentication provider and get a client id. Both the client id and ID token are required to sign in the second app which will generate it's access token.
What grant type are you using?
Both apps need to redirect the user:
In the first app the user will authenticate and the app will get an access token scoped to that app.
In the second app the user will be automatically signed in without needing to reauthenticate. The app will then get a separate access token, generally with different privileges to that of the first app.
This is standard SSO behaviour and it is best to accept it. Usability is pretty good. Trying to share tokens is not advised unless you have advanced requirements.
I have a web app (C# / Javascript) where I want to call a back-end service that I own. I want to secure that service so only my app(s) can call it. Seems like if I use Oauth on the client side, the secret is exposed? All the docs I read about Oauth give solutions when the user of the app owns the resource, not when the app itself owns it. I was looking at how google apis work, and the JavaScript libraries seem to expose the key on the client side, no?
Yes you can accomplish this with OAuth, but how you go about it depends on the details of how the data accessed via your back-end service is organized. If the data is actually user-specific, then your user really is the resource owner. In this case you would use the typical authorization code grant. With this grant type you register a client with the OAuth auth server and receive a client_id and client_secret. The client_id is, indeed, exposed in the browser, but the client_secret sits in your web app server and is never exposed. It is only sent on back-channel (non-browser) requests to your auth server. The main thing here is that only your own client web app would be registered and receive the client_id/client_secret. You simply need to not provide any public registration endpoints so no other clients can register. With this grant type, in order for your web app to gain authorization to access the user's data on the back-end service, the user would need to approve the authorization in the browser as part of the process.
On the other hand if the data you're accessing on your back-end service is not user-specific, then you can use the OAuth Client Credentials grant. With this grant type you register the client as before and receive a client_id and client_secret. The secret is stored securely on your web app server and only passed in back-channel requests. You would avoid allowing any other clients to register. Your web app can then gain authorization to your back-end service without even needing any user authorization in the browser.
I'm afraid there is no way to restrict your API to be called just by the code of your applications. Browser applications with public codes cannot hold any secret (such as certificate), that would identify them, because anyone can extract it from the code. Desktop and mobile applications compiled to bytecode are not so easy to read, but with some effort, attacker could find the secret data. That's also the reason why these applications (so called public clients) don't hold client_secret if they act as OAuth2 clients. They use a one-time secret instead - PKCE.
What you can do, is to check the audience (what client ID the token was issued for) of an access token sent from a frontend application to your backend. You can get this info either from the token introspection endpoint (aud attribute) or from JWT attributes if the token is of JWT type.
For my current work project we're trying to use OAuth to secure a mobile API, but the app doesn't have user accounts, so authentication would take place invisibly from the user, where the app will send up some secrets to the server and receive the token to be used for subsequent web service calls. The problem is, all the libraries and tutorials I can find implementing OAuth follow this pattern:
Present a web view allowing a user to login
Receive a callback to a custom URL scheme, and parse the necessary information to authenticate future web service calls
How do I achieve this without the webview step? I should be able to make an HTTP request directly with the correct credentials which will return the necessary authentication details.
The app will use OAuth 2.0
It is not clear what do you mean by
the app doesn't have user accounts
If you want to call some API on behalf of user you should ask him for a password. Doing it in webview or not depends on provider implementation. For example, twitter doesn't force you to do that.
In other case, if you want to call service on behalf of client, take a look at this answer: https://stackoverflow.com/a/7477112/2283405
If the app doesn't require "personalised" or "user-specific" data to be manipulated, then you can probably try using "client-credentials" grant type to obtain access tokens using the application credentials granted upon the application registration process by the Authorisation Server (for e.g.: OAuth server) that's there in your environment. The idea is that, your app is what basically authenticates with the Authentication Server for you using the aforesaid credentials (i.e. Client Consumer Key and Client Secret Key).
NO, you have to do login compalsary. if you try without. it won't be possible.
So I've been reading some documentation on Oauth, and I understand the concept and the way Oauth works, but I am having trouble understanding something...
On the following website, I took this excerpt (see emphasis):
In everyday web transactions, the most common credential used is the username-password combination. OAuth’s primary goal is to allow delegated access to private resources. This is done using two sets of credentials: the client identifies itself using its client identifier and client secret, while the resource owner is identified by an access token and token secret. Each set can be thought of as a username-password pair (one for the application and one for the end-user).
So lets use Instagram as an example,
Client = Instagram iPhone App
Server = Instagram Server
Resource Owner = Instagram User
My question is, how does the client store the client identifier and client secret inside the iPhone app when Storing passwords in iPhone applications is known to be completely insecure... Where does one store the client identifiers and client secret securely for oauth access?
I want to provide a service using the facebook api to third parties. Is it possible for us to share access tokens? If the third party gives my service a user's access token, can I access that users data even if my app_id & secret do not match the app that requested it?
Should I have the users go through a separate oauth flow on my site even if they have already completed it for the other third party?
Thanks.
-ken
Even that user access token is issued only for one app it can be easily used from any other application.
Example:
Get access token for "Graph API Explorer" application here https://developers.facebook.com/tools/explorer/?method=GET&path=me and make a request - you will see your data.
Copy access token and open other machine|browser and go to https://graph.facebook.com/me?access_token=[access_token] - you still able to retrieve information about your Facebook user!
Here https://developers.facebook.com/docs/concepts/login/access-tokens-and-types/ it mentioned that
Our Data Policies explicitly prohibit any sharing of an Access Token for your app with any other app. However, we do allow developers to share Tokens between a native implementation and a server implementation of the same App (ie. using the same App ID) as long as the transfer takes place using HTTPS.
Regarding:
Is it possible for us to share access tokens?
and,
can I access that users data even if my app_id & secret do not match the app that requested it?
The answer is No. From the specs OAuth2 section 10.3:
Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued.
Should I have the users go through a separate oauth flow on my site even if they have already completed it for the other third party?
The answer is Yes. If you're using facebook as authorization server, and you restart the oauth flow again, your user will only need to approve your other app (third party).
Each access token is issued only for one app - it cannot be used with different application IDs.