Develop Reference

How do I secure a Python API with in-the-open authorization tokens?

I have setup a simple REST API server (using Django REST framework) that responds to POST requests by doing some processing on an image uploaded to the server in the request. Previously I used it to power my own frontend (http://lips.kyleingraham.com) as a demonstration but I would now like to open the API to other users.
I would like for an end-user to be able to sign up and, from a dashboard, generate a token based on their credentials that could then be hard-coded into their web app. The sign-up part I believe I can handle but I am unclear on how to restrict a generated token to a user's web app domain. I know that the code for a web app is easily inspected so any API token I provide would need to be policed on my backend.
How can I restrict an authorization token to a users' web app domain so that even if the token was leaked, another user would not be able to utilize it?

If you want to hard-code url into user web app, in that way you can't guarantee that if someone get the token, he won't be able to use it.
The only idea is to set some time limit for each token

Azure AD Authentication through Python Web API

I am building a Python web API where I want to use Azure AD as authentication backend. On certain scenarios the clients needs to authenticate through the API to authorize to certain endpoints. The client itself is not able to authenticate to AD directly, so it needs to do it through the API using raw credentials (username, password). The API will then authenticate the user and receive the AD token and give it to the user.
So in short I am looking for a way to programmatically authenticate a user using username/password and receive the token using Python.

You can find the different authentication flows relevant for an application type and topology in this Azure AD article. The article links to the protocol overview for the authentication flows if you choose to implement.
There is also the ADAL Python auth library for Azure AD which you can use to do these flows.
Based on your scenario, you have a few options. If your client app can authenticate directly with Azure AD, you can take a look at the client credentials flow sample. If your application needs a user to authenticate and can have the user authenticate interactively, you can check out this auth code flow sample. Finally, if you must use the user's credentials to authenticate programmatically(without user interaction) in the app, you can refer to the resource owner password flow, but this is not encouraged as mentioned in the other answer.

What you are describing is the OAuth 2 Resource Owner Password Credentials Grant flow.
Note: using this one is in general a really bad idea and some other flow should be considered instead.
What you are doing here, is sending POST request containing user credentials in clear text directly to the authentication endpoint. Thus bypassing all possible added security that might be put in place.
Also, it will not work when
MFA is enabled for the user
User is federated or a MS account
This flow has no way to handle expired passwords
Consider some other authorization flow if possible, you got e.g.
Authorization code flow
Implicit grant flow
Client credentials flow
Device authentication flow
See this link to help you select which flow to use.

Integration of Angular website with SAML (SSO)

I have a website with frontend in AngularJS and backend in Python.
Currently we are presenting the user with a simple webform to fetch credentials.
The credentials from the form are sent to the Python backend(flask webservice)(this is a basic auth mechanism).
Now we would like to enable Single Sign on (SSO) on the website.Our identity provider is Pingone or Ping Federate.
I am starting from scratch here..with no prior knowledge of SAML or SSO.
I would like to know which path to take?
Which libraries to use and more importantly,how to use them?
At this point in time I am not sure how exactly SAML identifies a user and then authenticates him/her.

The basic exchange of SAML starts with a user asking for a resources (page, SPA app) on your Python server. The server determines if the user is already authenticated (has a session, JWT token, etc), and if not, creates a SAML request token to be sent via a redirect to the Identity Provider (use a library for this).
The identity provider verifies the SAML request token via digital signature. Once the token is verified, the user is asked to log in (if they are not already authenticated there). Once the user is authenticated, the identity provider creates a SAML request token which is presented back at your server via a redirect.
Upon receipt of the SAML request token, your server validates the token via digital signature, and you treat the user as logged in (again, use a library for this part). The token will minimally identify the user, but can contain authorizations and additional info. At this point your user is authenticated and you would create a session on your server or you create a JWT token to identify your user from within your angular app to the Python backend.
Creating the SAML request token and processing in the resultant SAML response token is not trivial. As suggested above, use a library, preferably one that has been through the the test of time. I'm not a Python dev, but I found this with some googling: onelogin/python-saml.
Wikipedia has a nice sequence diagram to demonstrate this and of course you can peruse the many docs on the Oasis SAML docs website.
Good luck with the implementation. I've done it a couple times in Java.

Django OAuth2 provider and resources on different servers?

I'm looking to set up Django to use OAuth2 to authenticate users for a service that I'm running, but I'm having a bit of difficulty understanding how the tokens are passed around.
I've been working my way through this tutorial: https://django-oauth-toolkit.readthedocs.org/en/0.7.0/tutorial/tutorial_01.html. I've been able to get a server up and running as the OAuth provider, and it seems to be working as it should. I'm able to log in to it and set up an application. The difficulty I'm having is figuring out how the various tokens are passed around.
Suppose that my OAuth provider is sitting on one server - let's call this Provider.com - and my service that I'm wanting authenticated is on service.com. When a user first tries to make a request to the service, they first need to authenticate against the Provider. So they click on a login button which directs them to Provider.com. They enter their credentials. If everything is set up correctly on the server, they should be presented with a prompt that gives them a chance to allow or deny Service.com from accessing their account on Provider.com. Supposing that they click Allow, they are then redirected to Service.com, and are given a token. On future calls to Service.com, they pass in the token, and are, in theory, able to make authenticated calls.
The problem I'm having understanding is this: At what point do the Provider and the Service communicate? If a call comes in to the Service, how does it know that the authentication token passed in with the call is valid? There's know way it could know that a particular token is valid unless: A) it recognizes that same token from a previous call which was also authenticated or B) it talks to the OAuth 2 provider and verifies the authenticity of the token.
A diagram like the one found here shows the process in the browser:
At the end of this, it has the Client App sending the authentication code, client id, and client secret to the OAuth2 provider. In the previously mentioned tutorial, it isn't really clear how this is actually done. In the tutorial, the provider and the service are on the same machine, and it would appear that they also share the same database.
This this brings about my question: How does one host a Django-based OAuth provider on a separate server than the resource/service being accessed? Is this possible?
From this other post, it indicates that this might not be possible: https://stackoverflow.com/a/26656538/1096385 Is that indeed the case, at least with the existing Django OAuth2 provider framework?

It depends on the oauth2 flow you're using. It seems like you're using authentication code.
In that case:
service.com sends the browser to provider.com for user authentication (uri contains service.com client_id and redirect_uri)
User authenticates on provider.com, then the browser is redirected to service.com's redirect_uri with a ?code parameter.
On your server side, handle this code parameter and ask for a token with it.
See https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#web-server-apps

How to make 'access_type=offline' / server-only OAuth2 operations on GAE/Python?

This post is a followup to How to do OAuth-requiring operations in a GAE cron job?, where I realized I'm mis-using the #oauth_required decorator from OAuth2DecoratorFromClientSecrets.
As described by the OAuth 2.0 explained presentation, Oauth 2.0 solves the problem of:
Building a service...
... accessed by a user...
... and accessing the user's data from a third party.
That's what #oauth_required abstracts, and it does it well (currently my app "works": if I trigger the refresh page, I'm being asked to authorize access to my youtube data to my app, and the rest follows). But that's not what I want! My app does something simpler, which is creating a youtube playlist every day with my credentials and without any user input. So to compare to the above 3-tier negociation, I want:
A service
... accessed by users
... but only accessing "server-owned" YouTube playlist data. I don't want any access to the user's YouTube data, I just want to modify a playlist I (i.e. me / a userid persisted by the server) own.
But I still need help to do that; here is my current state:
After a few searches I learned that what I want to do is called Offline Access (emphasis mine, which is almost exactly my use case):
"In some cases, your application may need to access a Google API when the user is not present. Examples of this include backup services and applications that make blogger posts exactly at 8am on Monday morning. This style of access is called offline, and web server applications may request offline access from a user. The normal and default style of access is called online."...
→ So I should keep doing what I'm doing right now, keep requesting access to my YouTube account, but do it using the type_access=offline flag to get a token, and persist/use it for subsequent requests.
The Offline Access and Using a Refresh Token sections make total sense, but stay at a general HTTP level. Being still a newbie, I don't see how to integrate those principles into my Python code, and I didn't find any sample Python code around....
→ Could anyone help me with one Python example illustrating how and where to use this flag?
... and in particular, after studying oauth2client.appengine.OAuth2Decorator.oauth_required, I'm still not sure if I can bend it to my case, or if I should do my own thing.
→ What do you think?
Thanks for your time; if needed I'm also hanging out on irc://irc.freenode.net/#appengine as ronj.

Offline access is the default when retrieving tokens; you may have noticed this in the OAuth dialog that comes up:
Perform these operations when I'm not using the application
When your user accepts the OAuth dialog in a method decorated with decorator.oauth_required the credentials for that user will be stored in the datastore, including the refresh token.
Once you have one of these credentials objects, you can use it so authorize an HTTP object for calling APIS:
import httplib2
http = credentials.authorize(httplib2.Http())
and once authorized, it will do all the work for you. So if the access_token is expired, the first API response will be a 401 and so the credentials object will use the refresh_token to get a new access_token and make the request again.
If you know the user ID, you can retrieve the credentials from the datastore as described in How to do OAuth-requiring operations in a GAE Task Queue?:
from oauth2client.appengine import CredentialsModel
from oauth2client.appengine import StorageByKeyName
credentials = StorageByKeyName(
CredentialsModel, user_id, 'credentials').get()
Note/Gotcha:
If a user has already authorized your client ID, the subsequent times you perform OAuth for these users they will not see the OAuth dialog and you won't be given a refresh token. A refresh token can only be given if they go through the OAuth dialog, but since the user had already authorized your client ID, the spec assumes you would already have a refresh token around.
This often comes up when developers are testing OAuth, since they will go through the flow multiple times with a test account and after accepting the 2nd, 3rd, 4th, ... times, they never see the refresh token. A simple way around this is to use approval_prompt=force as an argument to the OAuth2Decorator constructor. This will force the OAuth dialog to appear every time you perform OAuth for a user.
However, this will not cause the dialog to show up every time a request is served for a given user; this would be a TERRIBLE user experience. Instead, the SACSID cookie from the request can be used (by the client library and some App Engine libraries) to determine who the current user is. Once the the library knows that current user, it can get your existing stored token/credentials for that user from the datastore and no jarring dialog will be needed.