Recently Google announced that they are supporting OAUth for Gmail IMAP/SMTP. I browsed through their multiple documentations, but still I am confused about if they support OAuth for installed applications.
1.
In this documentation they say:
Note: Though the OAuth protocol
supports the desktop/installed
application use case, Google only
supports OAuth for web applications.
But they also have a document for OAuth for installed applications.
2.
When I read the OAuth specification pointed by them, it says (in section 11.7):
In many applications, the Consumer
application will be under the control
of potentially untrusted parties. For
example, if the Consumer is a freely
available desktop application, an
attacker may be able to download a
copy for analysis. In such cases,
attackers will be able to recover the
Consumer Secret used to authenticate
the Consumer to the Service Provider.
Also I think the disclaimer in point 1 above is about Google Data APIs, and surely IMAP/SMTP is not a part of them.
I understand that for installed applications I can have a setup like:
Have a small web-app at say example.com for my application. This web-app talks to Google gets the access token.
The installed application talks to example.com only to get the access token.
Installed application then talks to Google with the access token.
I am now confused.
Is this the only way?
Also, if I do OAuth from desktop application we have to ship the Consumer Secret key with the app. Then, we can't maintain secrecy of the consumer key.
Yes, Oauth is supported for installed applications; see Gmail IMAP and SMTP using OAuth documentation.
Documentation is simply outdated (2008)
It makes sense but just for application that does not store access token in a safe way.
Your setup is good although i don't think having a web-app that talks with google is mandatory; for example your users could just copy and paste "request token" to your desktop client application.
Related
I have an old windows application written in VB.NET with SQL server backend. Currently the new user additions, deletion, adding entitlements etc. are managed by an old approval workflow system. After getting approvals, the user details and entitlements are inserted in to the SQL server database table manually.
I am trying to integrate this application with the SailPoint's Identity and access management. So the new user addition, deletion update and adding entitlements etc will be done through Sailpoint. For this, I would require to create a WEB API which can be called by Sailpoint and expose the functionalities(add user/delete user/add entitlements). The only consumer to this API is SailPoint.
I am new to OAuth and below are the grant types that I came across. But not sure which one I should be using in this particular scenario.
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
I have done research on the different authentication methods that we can use to secure the web api. But still confused on which one to apply in this scenario as this new web api is going to be made available in internet.
I already tried developing a POC with the OAuth 2.0 with password grant type referring this article. But when I read articles in the internet I found that the password grant type is not that secure and is deprecated.
Could you please advise on which grant type(client credentials/authorization code/implicit) to use in this scenario. I believe authorization code is used when the user is directly trying to access the API. In this scenario, SailPoint will be calling the API in the backend programmatically when they insert a new user in their UI.
I think it's a good approach to use client credentials in this case because the communication between IIQ and your Web API can be considered an API-to-API communication, I mean, IIQ is acting on behalf of itself in this communication.
See this article for more details - https://dzone.com/articles/four-most-used-rest-api-authentication-methods (bold part by myself)
OAuth 2.0 provides several popular flows suitable for different types
of API clients:
Authorization code — The most common flow, it is mostly used for
server-side and mobile web applications. This flow is similar to how
users sign up into a web application using their Facebook or Google
account.
Implicit — This flow requires the client to retrieve an
access token directly. It is useful in cases when the user’s
credentials cannot be stored in the client code because they can be
easily accessed by the third party. It is suitable for web, desktop,
and mobile applications that do not include any server component.
Resource owner password — Requires logging in with a username and
password. In that case, the credentials will be a part of the request.
This flow is suitable only for trusted clients (for example, official
applications released by the API provider).
Client Credentials —
Intended for the server-to-server authentication, this flow describes
an approach when the client application acts on its own behalf rather
than on behalf of any individual user. In most scenarios, this flow
provides the means to allow users to specify their credentials in the
client application, so it can access the resources under the client’s
control.
I'm fairly new to programming, I've just got the basics down in terms of object oriented programming and a little bit of databases. I was just wondering if anyone could give an in-depth explanation as to what Google's credentials.JSON file does when trying to use their API. I'm using visual studios and c# if that's important.
Google's credentials.JSON contains information about your application that will identify it to google. It also gives your application some information it needs in order to find Googles oauth server and use it.
You should be aware that there are three types of files. Web, native and service account. The files are designed for use with different types of applications.
A web application would use web credentials and the code designed for authorization with a web application
A native application would use native credentials and code designed for use with authorization of a native application.
An application which would be just for server to server communication between data the developer owns and does not need to access user information would use service account credentials and the code needed for authorization with a service account.
Below is the example of the oauth credentials used for a web application.
{
"web":{
"client_id":"450547033183-5uok2fl5u.apps.googleusercontent.com",
"project_id":"developer-info-2b41cd",
"auth_uri":"https://accounts.google.com/o/oauth2/auth",
"token_uri":"https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs",
"client_secret":"Fu8ZmTGOMvHjqQEseZE68hg",
"redirect_uris":[
"https://developer-info-2b41cd.firebaseapp.com/__/auth/handler"
],
"javascript_origins":[
"http://localhost",
"http://localhost:5000",
"https://developer-info-2b41c.firebaseapp.com"
]
}
}
client_id Identifies the client to google so they know which oauth client this is you can create more then one set of credentials per project.
project_id your project on Google developer console.
auth_uri The Url endpoint you will need to contact google to authorize
token_uri The uri end point you will need to request the initial token.
auth_provider_x509_cert_url The location of all the oauth certificates
client_secret think of this as the password for your client id.
redirect_uris Authorized urls where you would like the authentication to be returned to.
99% of this is used by Googles Oauth2 server to authorize both your application and the user attempting to login. If your interested in how Oauth2 works i suggest reading though some of the RFC's for Oauth.
I have generated a Client ID and Client Secret for my application using the Google API Console for my Java web application.
I want to generate an access token to be used in my application to authenticate a mailbox and read mails from there with the help of JavaMail API.
This link has some theoretical information but I could not understand how the tokens can be obtained.
Answer will depend upon where is application running as it determines how access token can be received:
Using OAuth 2.0 for Web Server Applications
OAuth 2.0 for Client-side
Web Applications OAuth 2.0 for Mobile & Desktop Apps
OAuth 2.0 for TV and Limited-Input Device Applications
There are different alternatives or libraries available to get access token depending upon the type of application and different specific mechanisms are defined around it.
So it will be then much easier to dive-in into the specific options available.
I'm writing a native application that works against a Google API. Upon registering my application, and despite its explicit designation as Native, the Google Developers Console provides me with a client secret.
As far as I understand the OAuth 2.0 protocol, native apps should never have a client secret, since they cannot guarantee its secrecy. Is Google mistaken in its implementation of OAuth 2.0? How should I proceed?
You are correct, the client secret isn't terribly useful in a native application from a being kept secret perspective. I suspect it's there mainly for consistency with the web application flow.
It does however have at least 1 useful feature... the original developer can reset it at any time, effectively revoking all refresh tokens bound to that client ID.
I would like to get some ideas on to properly handle Salesforce OAuth Consumer Key and Secret in Chrome Extensions and Gmail Gadgets. Chrome extensions are essentially Javascript wrapped up in a zip compatible format. If I need to build an extension that calls Salesforce APIs on behalf of the user, I have to embed the Salesforce generated App OAuth Consumer Key and Secret in Javascript for the extension. This creates the possibility of disclosure of the OAuth Consumer Key and Secret, and possible misuse.
I am curious as to how other developers are handling these OAuth Consumer Key and Secrets in Chrome Extensions.
Google provides anonymous Consumer Keys and Secrets for Chrome Extensions that need to access Google APIs. However Salesforce doesn't provide similar OAuth setup. Is this on the roadmap for the Salesforce OAuth 2.0 implementation?
Here are a couple of options.
1) Run a proxy through your own server that protects the secrets and limits the allowed methods through your own API. This will also allow you to update the API keys in moments instead of the potential days to update an extension.
2) Obfuscate the secrets in the extension/gadget code. You can make it difficult to find but with Chrome it will be easy to pick out the keys in the dev tools network tab.
3) Say screw it, leave them in the code, and make sure no actual damage can be done using the secrets.
As for Salesforce's roadmap you will likely have to ask them and they probably won't comment.