I have a scenario where I need to add authentication & authorization to a native iOS / Android application. The app allows employees of a store to perform their business operations:

• Every store has an account created for it on the server.
• Multiple devices can be used within the same store. All of the devices in the store should access the same data.
• Multiple users (employees) can use any of the devices within the store.
• Identifying the actual user performing a certain operation is taken care of within the app itself.

I looked at the available flows and I'm a bit confused on what would be the best fit in this scenario.

1. I thought about using the Device Flow but I am not sure it's the right thing to do here knowing that the mobile device is not an input-constrained device (such as a fitness tracker or a smart TV).
2. The Client Credentials flow is also not a good fit because a mobile device cannot securely store secrets, and because I'm not just looking for authorizing requests to the server, but also in a way authenticating the store itself so I could return its specific data.
3. I'm left with the Authorization Code with PKCE flow but I'm still not sure if that's the right way to go knowing that I'm not authenticating users, but rather a device that belongs to a store. So, maybe I can think of the store itself as the Resource Owner and a privileged individual that works in the store (maybe the store owner) would use this flow to authenticate the store.

Do you think (3) is the right approach or do you recommend a different flow?

CodePudding user response：

I understand the concerns, since you need a middle ground between security and manageability. Aim for an option that meets immediate requirements but has good future possibilities also.

PREFERRED FLOW

The code flow will be the right choice since it has the best flexibility. Use the AppAuth pattern from RFC8252.

FUTURE PROOF SECURITY

The things to think about for the longer term are the abilities to perform one or both of these, which can be done in various ways:

• Identify the user
• Identify the device

Code flow allows for various choices:

• Convert your current in app user identification to a custom authentication action that runs during the code flow - you might use that as the primary factor, or perhaps as a secondary factor

• In future, store employees could sign in via a user friendly device such as a WebAuthn key instead of a password

• Mobile apps can store a client credential if it is distinct per device. In higher security setups this can be a strong cryptographic credential. More about this in mobile best practices. This enables you to identify the device.

Of course, you don't need to do all of this, but the tools exist when using the code flow, and adding more advanced security does not usually require any code changes.

INITIAL ROLLOUT

The tricky part is designing an initial rollout without blocking issues. Another option might involve something like 2 user accounts per store - one with admin rights - and use of simple passwords.

You should of course also think through threats - eg how to track the user if a malicious action was performed by one of the employees.

CodePudding user response：

There are two questions raised by the OP:

Q1. What OAuth 2.0 flow is appropriate for a native mobile app?

Q2. Who is the resource owner and how to go about authenticating them?

A1. Authorization Code with PKCE will work well for the native apps in a store.

A2. Based on the information provided by OP, store itself is a resource owner. Each store has an identity defined in the auth server, presumably with a credential, e.g. a password. In this case this identity will be used by all store employees to authenticate to the auth server. This will simplify token creation because the subject of the token will be the store itself. The identity of the employee will be handled outside of OAuth 2.0 exchange by the application. This will satisfy the requirement that all employees will have access to the same store-wide data. This is easy to implement in the resource server because the subject of the token is the store.

The application will have to be locked to the use of a single identity in a given store. This will avoid human error by an employee who works in multiple stores. This can be done at the application level in several ways.

Store identity can be simply configured by a store admin on each device.

If device rotation is possible between stores or if a personal mobile phone is used by employees and if they travel between stores, then the app could make a call to an API that returns store's identity based on the IP address of the store. This will also restrict use of the app to the internal network.

In either case an employee will only have to enter store password when authenticating to the auth server.