I am working on an automation tool that does not support Oauth specifically, but it supports adding URLs, payloads and has the following authentication methods: Basic, Digest, API Keys.
Is there a way to work around OAuth where I only use the above information and without using a callback URL so that the process is programmatic ?
Not enough information is available on this, but I tried with Google mail and had no luck.
Related
There seems to be very little information about getting started with Google's Drive REST API, besides the Quickstarts section (https://developers.google.com/drive/api/v3/about-sdk). I am trying to use their API in AutoIt, but I can't seem to find out how to generate an access token without using one of the available quickstart libraries. I am aware of the REST API docs (https://developers.google.com/drive/api/v3/reference/), but still, can't find anything about generating the access token. I have already generated a Client ID and a Client Secret though. Any help is appreciated.
Google's OAuth endpoints can be used with any library (or you could roll your own, but there are plenty of quality libraries). There is plenty of documentation of OAuth2 at Google, and there is the OAuth2 Playground where you can experiment with OAuth and the Google APIs.
If you have a library, Google's OAuth endpoints are available in the OpenIdConnect discovery doc at https://accounts.google.com/.well-known/openid-configuration
I've been trying to integrate OAuth2 authentication in my drf application. Given I don't yet need a front-end for my app, I was using the browsable API. DRF and the OAuth2 provider package are supposed to work together without much configuration, as explained in the tutorial.
I should mention that all the steps from the tutorial are working (so I can access the app from the command line) but when I try to do it from the browsable API, I don't see any request for an access token or anything like that.
I think that DRF does not actually provide the flow for the front-end part of authentication by OAuth2, but I was just wondering if someone managed to make it work (because for now I am using SessionAuthentication).
Thanks.
OAuth2, unlike basic authentication and cookie-based authentication, does not easily work within the browser. When authenticating requests, it relies on the Authorization header being present (with the OAuth type) and there is no way using a browser to easily fill that in.
Session authentication relies on cookies, which most browsers easily support, and is recommended for interacting with APIs that are on the same domain as the front end.
Basic authentication also relies on the Authorization header, but uses the Basic type which is supported by most browsers.
I am struggling with understanding how to implement the following in Web API 2's OWIN pipeline.
I am building an application that will allow users to log in with several third-party identity providers such as Facebook, Twitter, LinkedIn, etc. However, I want the authentication step to be performed entirely client-side. For example, Facebook provides developers a snippet of markup and JavaScript that perform the authentication within the browser, resulting in a Facebook access token--all without any calls to my API.
The Web API templates that ship with Visual Studio 2013 all seem to assume that the API itself is in charge of the authentication flow. I have successfully gotten this style of authentication working, but in my opinion it is not the responsibility of the API to perform this work.
Here is the approach I have been trying to implement (so far unsuccessfully):
Provide endpoints like /authenticate/facebook that accept the appropriate access token and return a JWT with "decoded" claims if the access token is valid. This JWT would have similar claims regardless of the third-party identity provider. For Facebook, I think this involves a call to Graph API's /me endpoint.
Store the JWT in the browser's localStorage for subsequent API calls
Send the JWT in the Authorize header for each API call
Avoid cookies if at all possible
My questions:
Is this an appropriate way to handle third-party authorization?
Should the JWT's expiration match the third-party access token's? I assume yes, but I want to be aware of any caveats here.
Where and how do I store the third-party access tokens for use on subsequent API calls? Do I include them with the JWT?
Is there a template I can use out-of-the-box, or perhaps an online resource that implements authentication and authorization in this way? I don't understand how to use Web API's many classes and features to implement this.
I have this mostly figured out now. I believe my architecture choice is the correct one after much research, specifically into the so-called "assertion flow." I am using Thinktecture's Identity Server 3 project to act as my STS. I am using a custom implementation of ICustomGrantValidator to perform the validation of the Facebook access token and conversion to claims.
I've an ETL tool that is capable of making REST API calls against the Yammer network and retrieving data for analysis. Currently, how I make Yammer REST API calls is through an App that I've created. I then generated the authentication token and then used this token in the REST API calls to get at the data.
What I'd really like to do now is to provide an app that allows me to call the REST API (using the same ETL tool) without the person installing the app to have to go through the rigmarole of generating the auth token.
I suppose one approach could be to use some JavaScript that displayed the token to the user so that they could then pass it on to us... Do you folks have any other suggestions as to how I might do this?
There isn't a recommended way to skip the OAuth authorization, but you can automate a lot of it away. I created a Python script that uses the YamPy library to acquire a token. It even fires up the browser to the correct URL for authorization. You should be able to do something similar with other languages.
Calling the impersonation endpoint is another possibility. This will get you an OAuth token for another user so you'd need to have an app is just for producing OAuth tokens. It's probably a bit trickier to build right and secure than my script. Impersonation was designed for a specific category of app which means I don't recommend it by default. Even when it is a workable option it hides the authorization from end users which can potentially be a security issue, if say you app is compromised and handing out OAuth tokens. At least if the Yammer screen is in the way it's a bit more visible to the user what is happening.
I am trying to develop a non-web application (mobile, non-mobile) for consuming information from Foursquare.
I would like to have the user authenticated by entering a valid username and password and accessing his account using this authentication.
Is this possible? From what I've read, it seems the only way to access Foursquare is by using OAuth, which is not what I had in mind.
Any thoughts?
Thanks!
RP
OAuth isn't a protocol that works only with webbrowsers. However, many OAuth services provide a web-only authorization endpoint. Once the authorization part is done, you can use OAuth from any application, web, desktop or mobile (and embedded systems).
There are many ways to handle this browser requirement, but these two are very common:
Simply embed a webbrowser in your application that shows the user the authorization page, let him log in, and finish the OAuth sequence. Once that's done, you have the keys and don't need the browser anymore.
Use an external browser. This is definitely the recommended approach, since it's more secure and users will probably like it a little bit more. The idea is that you simply open the authorization URL using the user's webbrowser, and set a redirect URL that points back at the app. This is normally done using a myapp://auth URL, which will simply send the data to the application again.
I believe OAuth is your only option if you plan on using the Foursquare api. You can read about Foursquare's Authorization here https://developer.foursquare.com/overview/auth