Open rpwagner opened 6 years ago
What you're describing sounds like the MRDP, but perhaps what you're saying is that we should have a simpler example than the MRDP (which is pretty hard to grok)?
Yes, even simpler than the MRDP. The Flask app doesn't need to talk to Transfer or any other Globus services besides Auth. It's more like the service example that's included in the MRDP, plus a minimal HTML page.
I'm a bit confused on why the Flask App supports Native App instead of Three-Legged-Auth; is the purpose to show how a user can do stand-alone authentication with Globus then use an Auth token they got to GET/POST/PUT/DELETE on a Flask API?
I agree with Nick's question. Seems to me that if you're using Flask, you're running in a web server, so you should be confidential (3-legged), not native.
Ah, the Flask app should not use Native App. Rather, it should be a REST API that a Native App can talk to. Like the service in the sample data portal. I haven't looked closely at the service example to see what the appropriate auth model is for the REST API.
A REST API shouldn't involve end-user authentication, because that authentication is done in the client. (The client needs to request the right scope during authentication, and then it will have a token that can be used in the service without any further authentication.)
The REST API is a "resource server" in the Auth API context. See Section 5 of the API doc for resource servers. (https://docs.globus.org/api/auth/reference/#api_for_resource_servers) Also, the section on API authorization in the SDK docs. (http://globus-sdk-python.readthedocs.io/en/stable/authorization/) It's a confidential app because it's running in a web server on top of HTTP, so its calls will use its client_id and client_secret to authenticate.
For backstory on the Modern Research Data Portal, it handled this example with two distinct Flask Servers:
If I understand the requirements right, if we're only doing the REST API Service Example we could do either Three-Legged-Auth or Native App, since the Service doesn't really care how a user derives their tokens, just that they're provided within the request.
The goal is to show a CLI Native App talking to a REST API authenticated with Globus Auth. The auth for the REST API should come from that goal. Since we have a full web site example with Django, perhaps the Flask one is just a nice, small, REST API, without a front end.
The auth for the REST API should come from that goal.
I think this is the part that's confusing for me. The REST API shouldn't do any kind of auth, right? It's either able to do work with a token provided or it fails and returns a 401 Unauthorized?
Right, that's what I meant.
Sorry for being pedantic, Auth is complicated.
The Flask example will be used to support the Native App CLI example, so it should produce both a web site and have a basic REST API secured with Globus Auth. The Native App will then talk to the REST API in both anonymous and authenticated mode to query and push to the API. A good example would be to anonymously query a set of allocations and utilization's, and then have an authenticated POST or PUT to modify it.