nest PIN-based authentication and PIN extraction - javascript

Background on the Application:
Embedded system that will connect to nest-api as a client to retrieve required data. This embedded system can connect to a wifi network and provides a web interface through which user can carry out authentication.
For authentication, currently the user is directed to
https://home.nest.com/login/oauth2...
and user can carry out the authorization procedure and get an 8-char PIN.
The user is then asked to input this PIN in a text box and submit it to the embedded web server which then requests the access_token (using C platform).
There are two questions related to this issue:
1) Is there a way to carry out request for access_token also from the client browser, and only return the access_token back to the embedded system? Any Javascript code that can request access_token after user inputs the PIN and submits?
2) The second issue is related to lack of automation. The user needs to type the PIN back in the web interface. Is there a way to extract the PIN from the website automatically using some script. For example, open the /login/oauth2 page embedded within another page and run a script on the main page to keep scanning the embedded page until the PIN becomes available (i.e. the user logs in and grants permissions). As soon as it becomes available, it can be copied and returned back to device web and access_token requested automatically.
I understand that this type of automation can be achieved by web-based authentication, but from my understanding that would require a proxy server for redirect URI. The idea is to make the device self-sufficient without a need for maintaining another server.

Yes, see the control-jquery sample code for an example of how to work with OAuth tokens in JavaScript
Nest allows you to use addresses that start with http://localhost or https:// as the OAuth Redirect URI. You can either run a web server locally, or monitor the WebView for a redirect URI pattern of your choice and parse the results.

Related

Posting form-data through another page

first of all before this gets marked as duplicate with CORS and X-header comments, let me prefice this by saying.. This question is strictly intended for LOCAL environments only.
I have written a website with .NET as backend that uses cookies and session-strings to maintain the authentication between the client and the website. However, a customer of ours want to disable authentication all together for all their users. Here is where the problem arises, our system rely on the fact that usernames and auth-data is sent along in most of our data-requests. So, the customer has agreed to use a static page with the username and password statically programmed (so that they wont have to login every time, but mearly open a chrome/firefox-shortcut on their desktop). This static page will redirect and pass along this static information to the "real" loginpage and sign in the user.
Illustration:
What are my options here?
Here's a screenshot of the req-headers in a successful login-post.
Thanks.
You want to serve your site from the backend and distribute a link to your site. Your client then bookmarks the link (or pins it to their home screen).
Serving static HTML files has fundamental limitations and you will hit a brick wall sooner or later (e.g. AJAX calls require the site to be served from some domain).
From here, there are a couple of options to do what you want.
The orthodox route is to delegate credential storage to the underlying OS. That is, just program the input forms as usual, issue Cookies as usual, and make sure the form HTML is such that the browser offers to save the credentials.
An alternative solution more in the vein of your initial proposal is to create what are known as signed URLs. You may create cryptographically signed URLs (e.g., http://localhost/your/site?hmac=<your_signature>) and hand that your client. Once you handle that URL in your server and verify the signature is valid, you may respond with a 301 redirect to your site, issuing the authentication cookie in the redirect response.
For background material, you may want to read about Post/Redirect/Get and Message authentication codes.

How can authorization be done on a local web app using Google?

I'm developing a (so far) intra-company website that needs authentication (i.e. a limited set of users are allowed to use it). I don't want to force the users to have a new username/password pair for only this service. The company already uses company-branded Google Mail for e-mail, so every user already has a Google account: my "cunning plan" is let Google authenticate the users.
I found this great question and answer so I know (or at least have an idea) on how to verify on the server side that the web session was authenticated by Google. What I don't know: how to get that accessToken on the client side? How to detect if the user already logged in to Google, and if not, how to present the Google login form to the user?
I found the Using OAuth 2.0 to Access Google APIs documentation, but I don't quite understand this sentence: "The authorization sequence begins when your application redirects a browser to a Google URL; the URL includes query parameters that indicate the type of access being requested.". What is this URL?
I'm fairly new to web development and JavaScript, unfortunately.
"The authorization sequence begins when your application redirects a browser to a Google URL; the URL includes query parameters that indicate the type of access being requested.".
Your application will need to open a webpage which will display a consent screen to the user. This page is opened on Googles identity server not your own. You have probably seen this before.
The url is built up using the client id and redirect URI that you set up on your project in the Google developer console.
https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
you might find this blog post interesting Google 3 Legged OAuth2 Flow

Call an office 365 authenticated web api from a sharepoint page javascript

I have a scenario that I think should be fairly simple, yet I'm not finding a solution and wondering if someone can point me in the right direction.
The setup:
1) SharePoint online website (user must be authenticated to see page)
2) .NET MVC Web API service endpoint (user must be authenticated to get data from the service)
Both of these authenticate using the same Azure Active Directory. The Web API has been registered in Azure AD.
The problem:
I would like to put some javascript on a SharePoint Online page (not a Sharepoint Add-in, not an AngularJS SPA) that will make an AJAX call to the Web API using the logged in user's credentials without any kind of user prompt (since this is an ajax call, the user won't see the prompt anyway).
I've tried looking into the ADAL libraries, but all the JavaScript ones I can find require the use of Angular and require the user to authenticate a second time. I've found some documentation using OAuth 2.0, but (from what I can tell) require you to get the client to authorize the Sharepoint Online page to act on their behalf - which the user will not be able to consent to because it's an AJAX call and the consent page is not displayed in the browser (and it's still doing this despite having the app already approved by an administrator in Azure AD).
It seems to me the user shouldn't have to leave the SharePoint page and shouldn't have to enter their credentials a second time. I believe there should be some way that the log-in to SharePoint Online should also be able to be used as the log-in for our in-house app.
If someone could just point me in the correct direction, I would be very much appreciate it. Thanks in advance.
Normally, if we call the resource which protected by Azure AD, we need to authorize the app via OAuth 2.0.
Were you able to put a hidden iframe in the SharePoint online page? If it is possible, then we can use the Azure AD implicit flow get the token through iframe, and we can call the REST which protected by Azure AD via the token return by iframe. To enable the implicit flow, we need to download the application manifest from Azure portal and switch ‘oauth2AllowImplicitFlow’ to true.
And if you were only developing a single tenant which doesn’t require users to consent the app. Here is the HTML code request the token from a Iframe for your reference:
<iframe width="0" height="0" id="oauthHideIframe" src="https://login.microsoftonline.com/{tenantId}/oauth2/authorize?response_type=token&client_id={Client_Id}&redirect_uri={redirect_Url}&resource={your web api app url register on the protal}"> </iframe>
And to pass the token from iframe to the parent window, we can use the window.postmessage which allow the corss-orignal communication.

Using Facebook API in widget

I'm building a widget that can be placed on a various sites, and will have users be able to log in via facebook connect to accounts on the widget's parent site. I was going to use the Facebook JS SDK to do this, but the widget will likely be placed on sites that already have the FB JS SDK initialized on them with a different app ID, and if I were to run code this way it could lead to a namespace problem.
The only current solution I have come up with is to do the server-side type authorization, and have a redirect-url that leads back to the current page in which the widget is hosted and use the state paremeter to alert backbone router that the user has logged in.
The first problem I thought of is that on the facebook docs site it says
For security, the redirect_uri must have the same base domain as that specified in the App Domain property of your app's settings, or be a URL of the form https://apps.facebook.com/YOUR_APP_NAMESPACE.
How do I bring people back to the original page that the widget it hosted on after login? Is there a better approach to this problem?
you can use Server side authentication and redirect_uri to your site that will redirect to the various site
redirect_uri = https://www.mydomain.com/?r=https%3A%2F%2Fwww.somesite.me
On you server you will look of the query param r and redirect the request to r value.
You can also do your own authentication for users (when they first sign in) and store there facebook access_token on you DB, once your widget is running (under https) and you identified the user on your authentication you can send the widget client the user's access_token and work with it.
You can even create your own Simple FB-like ajax library, for most things it will be a simple get/post/put calls with access_token as a url parameter
Hopes it helps

Chrome extension / web app session control

I am creating a chrome extension, rather a chrome webapp. This application just contains the html, js, image and css files. The application connects to a server to fetch data. I chose to do this as it would reduce the amount of files downloaded by the user. Using Backbone.js I have an MVC architecture in my application. Thus the application just sends json.
Now having said this, I need a session management. I plan to use Google authentication as the organization has Google Apps. I need a method that once the user has logged in using google auth the server get the user name every time the application makes a request.
Is it a good idea to add the user name in request header, if possible. Or should I use cookies? Can any one tell me how I could go about using cookies in this case?
This might be a late response but I want to present a more elegant solution to you given that the user has cookies enabled in their browser.
First read my answer on another question.
Now that you can send cross origin xhr from your content scripts all you need to do is store all your authentication and session management at server only. That is right, you just need to display whether the user is logged in or not and a logout button at client based on server response.
Just follow these steps.
At client Whenever user accesses your chrome web app, blindly make XmlHttpRequests to your server without worrying about authentication, just keep a tab on response from server which I describe below.
At server whenever you receive a request check for valid sessions or session cookie. If session is valid send proper response, if not send error, 401 or any other response to communicate to your client that session is not valid. It is better if you send an error code like 401 since then you can put a generic script at client to inform them that they are not logged in.
At Client If response from server is proper, display it, else display login link to your website.
IMPORTANT: Display logout button if user is logged in.
Check out my implementation of this in my extension
For help using Google authentication in your app take a look at Google's OAuth tutorial which comes with all you need (took me no time to set it up using this).
As for session management. The implementation of OAuth used by Google stores the tokens in localStorage. Also, as briefly mentioned in the extensions overview we are expected to use localStorage to store data. Thus, I suggest you store the users name here as it will be accessible throughout the app's lifetime (until it is uninstalled). However, you may need to manage the name stored here and consider what should happen when users log in and out. That said; I'm not sure if sessionStorage would be a better option as I've never used it before, let alone in an extension.
Note
localStorage and its counterparts only store strings so I suggest using a wrapper which uses JSON to parse and stringify to get and set your values respectively.

Categories

Resources