Fair warning: I’m out of my element here after some unfortunate layoffs in these parts, but I’m hoping Auth0 will make this possible.
Here’s the simplified relationship I’m trying to establish: We host a JSON object repository (R) which allows any unknown application (A) to “register” and then save any object. There are a few tangles:
When a new A registers, R creates a public object representing A to the public, which I think I need to store the location of in Auth0’s record for A;
All A’s interactions with R are server to server—even if A has a front-end, calls to R must be proxied through;
R writes a private property onto the object to be stored, which should be a trusted location of the public A object.
At first pass, I thought each new A would be a User in my Client for R. I created a rule that POSTed the public object, read the response, and wrote the URL into app_metadata.agent on the User. This worked until I tried to imagine how a User (someone’s A) would get an access_token without a web interface. That is, the human user of A does not need to be known to R at all; only A itself needs to authenticate (and so “login” or “getToken” or something) from its own backend (Java, Node, what-have-you) and then pass a token to R with the actions it is attempting. Then, I reasoned, R would always getUserInfo/TOKENand write the value of user.app_metadata.agentinto the object before saving it (also confirming that the requestor is authorized, by the way). Alas, I cannot find a back-end way to “login” as a User-cum-application.
So, I thought, I could use the dynamic client thing which would give me access to all points of the API and solved that issue, except now I don’t know how the app_metadata.agentvalue could be recorded somewhere behind authentication reliably.
Is this impossible? Do I need a web interface for the developer to get an access_tokenand then manually plug it into their code and trust them to update it whenever it expires?
hi @cubap thanks for the detailed scenario, however it’s making it quite impossible to understand what you’re trying to achieve… can you please in a paragraph explain the use case in a less technical way so I can help you with your use case ?
Sure, thanks for the attention, @lobo. I think we’ll be hosting an interface for application developers to pick up persistent access-tokens as API Keys.
The case is about the data repository, RERUM (rerum.io). Currently, the registered applications leave an IP address for a whitelist to be allowed to write to store.rerum.io/annotationstore (like this object). We would like to be able to have them be authenticated through Auth0 instead. RERUM is a web service, without an interface and it only allows server-server communication (no CORS, for example) so we can restrict usage (more or less) to actual web applications serving scholarship.
The imagined flow, then, would be that these applications would sign up as users in an Auth0 RERUM client. My hope was to offer them a direct or proxied set of endpoints to “login” to grab an access_token, refresh expired ones, or release compromised ones. It would be nice if this could be automated (so as a developer, if my app gets a 403 from RERUM because my token expired, I can get a new one with my credentials and continue the request) to run from the server. The documentation looks like “users” can only do this through the lock widget. It may have been intended that these sorts of applications become Clients (and so the Dynamic Client Registration, etc.), but that does not seem to allow me to write any metadata back or request custom fields the way we can with Users.
Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.
Wanted to reach out to know if you still require further assistance?
