I am developing a PhoneGap application and require my users to sign in through Google with OAuth2. Is this possible directly through JavaScript? I have almost no experience with JavaScript (and jQuery).
What are the options? I have thought of a cumbersome alternative which involves posting the username/password to an application I have hosted on a server which then takes care of logging in. Then the PhoneGap app will have to ask the server if the authentication was successful. However, I was hoping there would be a simpler way.
What is the best way signing in through Google on a PhoneGap app?
I have managed to get it working! I'm posting my thoughts here because I had a hard time finding the answer after hours of searching the web.
The important steps are:
Make sure ChildBrowser works properly
Setup a function that will listen to page changes
window.plugins.childBrowser.onLocationChange = function(fooUrl) { console.log(fooUrl); }
Build the URL with the query string as described in this tutorial
Point ChildBrowser to the URL
When the user logs in, you will be able to extract the session token from fooUrl
If you still don't know how to do this, have a look at this Android app.
(There is a lot of code, and it might seem overwhelming, so I suggest only going for this as a last resort)
Google will not allow you to perform direct authentication by handling the user credentials directly. Instead Google wants you to perform an authentication protocol, typically OAuth 2.0. Other popular authentication protocols you may hear about is OpenID 1.0, 2.0, OpenID Connect, SAML 2.0, ID-FF, etc. These protocols will redirect the user to the Identity Provider (Google, in this case), and send you back with an assertion that you may use to trust the user. With APIs, like Google, you would make use of the authorization functionality of OAuth, which provides you with a token that you may use with all Google APIs after authentication.
A good introduction to how OAuth 2.0 works
With PhoneGap and mobile apps, things are a bit different than the typical OAuth setup.
In your case, the browser is in a controlled environment, your app, and you may
select to redirect the user to Google Authorization endpoint using the main view,
select to open a ChildBrowser with the Google Authorization endpoint, to not lose any state on your app.
to somehow open Safari or another browser with the authorization endpoint, and register a custom schema handler, to redirect the user back to your app after authentication.
These examples are vaguely mentioned in the OAuth 2.0 specifications, but there are no aid in what is the best or optimal in a specific use case. Often the best possible option is not perfect (from a user perspective).
I recently wrote a tutorial on how to make this work with Phonegap and ChildBrowser for iOS.
OAuth 2.0 Guide for Phonegap using ChildBrowser and JSO
Related
I've currently got a REST API (written in Java using Spring) and a frontend for that API (written in Javascript using Express) which will query that API for the data to display. I've not gotten too far along in the frontend, and wanted to add in my Authorization/Authentication. I would like to use Azure Active Directory (AAD) for this - we have users in AAD, so this is what we're pursuing. I understand that I can use the MSAL.js library to get an access_token that I can then send to my Java REST API for validation. However, I'm not able to find any decent documentation or examples for this specific case, though. I see a some Javascript Single Page Application (SPA) documentation and examples, but seeing as this is AuthN/AuthZ, I don't want to have a kinda correct solution, because this is important stuff. I also want to make sure I'm handling caching, sign outs, etc, in the right manner.
If anyone could point me in the direction of some documentation, examples, readings, etc, I'd be very appreciative!
Thanks!
You can use MSAL.js to easily integrate with the front end of your API for authentication/authorization of your users.
For java web apps, you can use the MSAL4J authentication library, so that the application can be integrated with the Microsoft identity platform. It allows you to log in to a user or application using a Microsoft identity (Azure AD, Microsoft account, and Azure AD B2C account) and obtain a token to call the Microsoft API.
For more details, please check:here.
I'm implementing Auth0 in my SPA app, one of the requeriments is to have a custom UI, that also implies that i cannot use redirects to the Universal Login Page of Auth0.
After reading throught the Auth0 website, i found the Resource Owner grant type, which seems to solve my problem to handle a login directly using Auth0 API.
Is there any drawbacks of using this grant type?? (I read that is not very recommended, but i wanna hear opnions about this)
Also, is there any alternative to this grant type?? I mean, i'm stuck with this solution if Biz doesn't want redirections?? Thanks.
Resource Owner Password Grant
This can sometimes be a useful 'bridging solution', but it has some disadvantages as summarised in this article from a couple of years ago. These are perhaps the main downsides:
Single Sign On across apps won't work
Federated login options won't work (Integrated Windows / 2 Factor)
Security reviews may perform less well
Redirecting for Logins
It is very standard to redirect users to login, which signifies that you are externalising security to an expert provider. Most systems do this, including Gmail and Office 365:
You start at mail.google.com
For logins you are redirected to accounts.google.com
You then return to mail.google.com
My blog page shows the login redirect user experience for Web / Desktop / Mobile apps and there is an SPA there which you can run.
Of course, if your app is well coded there should be no down side to redirects. Eg the app should maintain the user location within your SPA, and also any data the user is editing.
As of now I am building out a custom Tumblr page which is basically aggregating post content into 1 page.
Problem is, we can't use the Tumblr tags for the Like, we have successfully gotten the Reblog to work, but when ever I try and use an hrefed to this pattern,
'http://www.tumblr.com/like/'+oath+'?id='+id'
and /unlike/ for unliking the post.
I can't get anything but an access denied page to come up.. Shouldn't I at least be seeing an authentication pop-up of some kind? Not sure what else to do here. Need to get this LIKE functionality working, and using the Tumblr {like button} is not an option since we aren't using a {posts block} rather pulling all our content in via JSON API.
Found an answer!
So let me break it down for you all.. I am just going to run down all the issues and caveats that were discovered while I was hacking away at the Tumblr API. In most cases you will not find any of these answers on the inter webs. If you do, they most likely will just be my answers to my own questions that I posted to the Forums.
A Tumblr Application is defined by any page template either hosted
by Tumblr or not that will be using the Tumblr API. Applications
must be registered with Tumblr at:
https://www.tumblr.com/oauth/apps
All Tumblr Applications upon creation are given a set of keys for
accessing the Tumblr API. OAuth Consumer Key aka API Key Secret Key
The Tumblr API is divided mainly into two different types of
methods. The third being “Tagged” which is for pulling tagged posts
from the Blog or the User.
“Blog Methods” which only require the submission of the Consumer
Key. “User Methods” which require a full OAuth signed request which
meets the OAuth 1.0a Protocol. The “User Likes” returns a maximum of
50 records at a time. This is not documented in the Tumblr API
docs.
Currently the Tumblr API documentation directs developers to use one of the many open source API clients. However, all these clients seem to be Server Side applications. For providers, such as Tumblr, which support only OAuth1 or OAuth2 with Explicit Grant, the authentication flow needs to be signed with a secret key that may not be exposed in the browser.
HelloJS gets round this problem by the use of an intermediary webservice defined by oauth_proxy. This service looks up the secret from a database and performs the handshake required to provision an access_token. In the case of OAuth1, the webservice also signs subsequent API requests.
HelloJS - http://adodson.com/hello.js/ is the only client-side Oauth library that was available and free. There are many services out there that charge on a per-api hit basis to serve as a proxy.
The HelloJS OAuth Proxy is available at: https://auth-server.herokuapp.com/
Login to the OAuth Proxy is done using one of the following social account credentials: Google, Windows Live, Facebook, or Yahoo.
OAuth Proxy serves as a secure “man in the middle” allowing for the “Secret Key” to be securely stored while still allowing for Client-Side OAuth authentication.
HelloJS features a special Tumblr Module - http://adodson.com/hello.js/demos/tumblr.html
HelloJS utilizes the new Javascript Promises asynchronous functions specification - https://www.promisejs.org/
Javascript Promises have some unique rules when it comes to passing objects received from an asynchronous AJAX call.
With everything is done in the callback.
What jQuery calls a promise is in fact totally different to what everyone else calls a promise.
Hope this helps for future Tumblr integrations.
John
I have tried using the node-xmpp package and blather gem. I got the furthest with blather, but succeeded with neither.
Blather attempt:
https://github.com/adhearsion/blather/issues/119
Node-xmpp attempt:
https://github.com/astro/node-xmpp/issues/149
From the Facebook API Docs:
Authenticating with Username/Password
The DIGEST-MD5 SASL mechanism is available to support traditional XMPP
or multi-protocol IM clients that are not customized for (or even
aware of) Facebook. This mechanism requires prompting the user for his
or her password; therefore, it should only be used when necessary. In
particular, it MUST NOT be used for any client that:
Proxies the XMPP connection (the connection must be directly from the user's computer to Facebook).
Reports messages or any other information about user activity to a third party (including the client developer).
Integrates with Facebook, or has a Facebook Application ID. If your application does any of the above, you must use Facebook Platform authentication instead.
I think your application is doing one of the following, correct me if I'm wrong but based on the links you provided for your blather and node-xmpp issues I think you may be trying to violate the third criteria.
Integrates with Facebook, or has a Facebook Application ID. If your application does any of the above, you must use Facebook Platform authentication instead.
Link: https://developers.facebook.com/docs/chat/
I am developing an iGoogle Gadget. I have to access the spreadsheet data of logged in user. How do I implement an OAuth for it?
You have to become an OAuth Consumer of the Google services - they are the OAuth provider in your case.
There are a lot of open source implementations of the protocol in various languages, but I would suggest to read through the RFC if you want to implement it - it's clearly written and not very long.
The official site has good reads and links too:
http://oauth.net/
Basically it's a protocol that exchanges a little bit of data between you (your application aka the consumer), the provider and your user with internal HTTP requests between you and the provider (exchanging tokens) and some redirects through the user's browser between you and the provider again.
Also, you as a consumer will have to store some tokens and data regarding these interactions. It's not very complicated and in the same time is very interesting thing to implement. I learned things about security, request signing, some http details and headers. And if you already know these things, then you will do it a lot faster than I did :)
OAuth is just an API that Google gives out to developers to let them authenticate Google accounts in other manners other than just going on google.com - for example through a programmatic way.
Authentication is the basis of it, but through OAuth you're able to retrieve lots of information from a specific Google account (calendar info, contacts etc.)
To implement this you would need to read more on their website:
https://developers.google.com/identity/protocols/OAuth2