[Help] Authentication + multiple types of accounts (Principals)

[cafe01]

First a quick description of my project.

Its a cloud service to provide MQTT servers for IoT gardening devices and client apps (that are also part of the project) to transparently connect to.

The user doesn't handle the MQTT connection (hostname:port + username:password). That data is provided by an API endpoint called 'check-in'.

User workflow:

• User sign-up, choose password;
  • new User is created
• User sign-in via client app, using credential;
  • receives access token (with a UserProfile payload)
• User check-in via client app, using access token;
  • receives MQTT connection data (hostname:port + username:password)

So far so good. I could implement that using what I've learned from the authentication + authentication-jwt docs.

But things get unclear to me when we introduce the device workflow. It also needs access to the check-in endpoint:

• Device sign-up (user enters out-of-band secret on device captive portal);
  • new Device is created, device receives its own credential
• Device sign-in (from his firmware, using its own credential);
  • receives access token (with, a... UserProfile payload??)
• Device check-in using access token;
  • receives MQTT connection data (hostname:port + username:password)

It seems to me that the device is another type of Principal that need authentication: exchange its
own credential for an access token. And that token must be decoded back to the device, not to a user.

PS: It's not like the device is consuming the API on behalf of the user.

What is unclear to me is that even though the security package exports the base Principal interface
(as well as a set of specialized interfaces, one of which is UserProfile), the authentication
package is hard-coded to use UserProfile all over.

The class TypedPrincipal (@loopback/security) seems the perfect candidate for what I need, but
its not mentioned anywhere.

For the sake of completeness, there is another entity (called App) in the project that also (as of my current understanding) represent a type of Principal. Apps represent extra services that a customer can opt-in: there is a service to persist device log to a log database and another service to persist sensor data to a metrics database. Both services collect data by connecting to each customer's server.

Those services are implemented as separate applications, and do not have access to the API database. They are API consumers and also need access to the "check-in" endpoint to retrieve the list of servers they must connect to.

Any help is welcome. Thank you.

[achrinza]

Thanks for opening a discussion!

I'm not too familiar on the reasoning behind the design choices, but for what it's worth, here's what I found:

1. UserProfile is used in the Authentication package
2. UserProfile is converted to Principal in the Authorization package (see)
3. The Principal from the conversion in (2) has enough information to convert into a TypedPrincipal, and will always have a USER type (see previous hyperlink).
4. There is a ClientApplication interface that extends Principal with no additional properties

If I were to guess, this design seems to have either...

1. had the assumption that all device auth flows skip Authentication, straight to Authorization - This could work for api key-based auth
2. been to work with limitations with Passport.js? (To be frank, I'm not familiar with the requirements of Passport)

From what I can observe, the following changes should be made:

1. Update the Authentication package to use the generic Principal in place of UserProfile
2. Add logic to allow Auhorization package to distinguish between different Principal sub-types

Also considering that there can be multiple Principal returned in a single authentication,

3. Allow an AuthenticationStrategy to return multiple Principal
4. Change SecurityBindings.USER_PROFILE to accommodate multiple user profiles

cc: @jannyHou @nflaig Would love to hear your input on this

[achrinza]

To further add on, in AuthorizationContext (the context passed to the Authorizer), only principals will have an array possessing the principal derived from the user profile. roles and scopes are always a blank array.

Again, I'm not familiar with the "why" in the design choice, hence I'd like to hear from the other maintainers who are better-versed in this area.

[nflaig]

@achrinza I think a AuthenticationStrategy should return a Subject (see) instead of a UserProfile since the subject is basically like an array of multiple Principal. But I have to say that I am not too familiar with the design of @loopback/security and I don't know the reason why @loopback/authentication was not updated, maybe @raymondfeng could give better insights on this based on this comment sounds like we should probably update the authentication package.