I’ve tried constructing a user object with only the auth token field set INSTEAD of the email and password fields and sending that up using SpeckleClientAPI.UserLoginAsync() but I get an unexpected 401 response. My use case is to get the rest of the user data from the server using the locally cached auth token or where ever else the user gets their auth token from. This way I can allow an additional overload for logging in with both regular credentials as well as just the auth token.Can this be done?
Hi @pablothedolphin! The UserLoginAsync() endpoint is to get an api token in exchange for a correct set of user credentials. Once you have that token, you dump it in the Authorization header of every request you make to the api, and the server will infer from it your identity, access level and the resources that you’re entitled to access.
Be wary, servers that disable the local strategy and accept only 3rd party identity verification, ie Github, Azure AD, etc. will NOT have the UserLoginAsync endpoint enabled. This means that, in those cases, the only way to do properly identify the user is via the sign-in window from the server - just like the AccountManager popup does it.
You can of course, for your use case, prompt the user to paste their api token (which they can retrieve from their profile page in the admin app).
AuthN and AuthZ are being revamped in 2.0 for an even more secure flow; you will not be able to call the login endpoint, if enabled, from outside the “same origin” - so it makes even more sense to move away from reliance on it.
Damn so for servers that don’t implement the local strategy, login via unity can’t happen at all since on mobile or other platforms you can’t use the Speckle UI to create the popup dialogues used in other clients.
I guess for the overload for my high level LoginAsync method, I’ll just have it accept a single string for the auth token then simply assign it to a new instance of an internal user object which is then used for all subsequent references to the auth token. And if the name or email fields are ever requested of that object, I’ll just pass some default value back.
What about servers that do implement the local strategy but the specific account that you’re trying to log in with is typically authenticated via github or azure ad? Would a login request still work?
I’m afraid not - the authN flow is purely between the server and the identity service at that stage; the server sends back a token if it’s successful. On unity/mobile platforms though, can’t you open the default browser with the siginin window from the server? If everything is ok, you get a token back via a http request on a local server (in the app!). As well, this is transferrable to 2.0, so it’s not wasted effort 
1 Like
That definitely sounds like the way it should work from the get go. Looks like I need to roll my sleeves up for this refactor!
1 Like