我有一个需要添加身份验证＆amp;的场景。授权授予本机iOS / Android应用程序。该应用程序允许商店的员工执行其业务运营：
- 每个商店都在服务器上为其创建一个帐户。
- 可以在同一商店内使用多个设备。商店中的所有设备都应访问相同的数据。
- 多个用户（员工）可以使用商店中的任何设备。
- 确定执行某个操作的实际用户在应用程序本身内得到照顾。
我查看了可用的流量，对这种情况下最适合的最佳状态有些困惑。
- 我考虑过使用设备流量，但我不确定在这里知道移动设备不是输入受限的设备（例如健身追踪器或智能电视）是否正确。
- 客户凭证流也不适合，因为移动设备无法安全地存储秘密，而且我不仅在寻找授权对服务器的请求，而且还以某种方式对商店本身进行认证，因此我可以返回其特定数据。
- 我剩下的带有PKCE流量的授权代码，但我仍然不确定这是否是正确的方法，因为我知道我没有认证用户，而是属于商店的设备。因此，也许我可以将商店本身视为资源所有者和在商店中工作的特权个人（也许是商店所有者）将使用此流量来验证商店。
您认为（3）是正确的方法还是建议不同的流程？
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.
- 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).
- 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.
- 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?
发布评论
评论（2）
OP：Q1提出了两个问题
。哪种OAuth 2.0流适合本机移动应用？
Q2。谁是资源所有者以及如何对其进行认证？
A1。使用PKCE的授权代码将对商店中的本机应用程序效果很好。
A2。根据OP提供的信息，Store本身是资源所有者。每个商店在Auth Server中都有一个身份，大概具有凭据，例如密码。在这种情况下，所有商店员工将使用此身份来验证验证服务器。这将简化令牌创建，因为令牌的主题将是商店本身。员工的身份将通过应用程序在OAuth 2.0交换之外处理。这将满足所有员工都可以访问同一商店范围内数据的要求。这很容易在资源服务器中实现，因为令牌的主题是商店。
该应用程序必须锁定以在给定的商店中使用单个身份。这将避免在多家商店工作的员工的人为错误。这可以通过多种方式在应用程序级别上完成。
可以简单地由每个设备上的商店管理员配置存储身份。
如果商店之间的设备旋转或员工使用了个人手机，如果他们在商店之间旅行，则该应用程序可以致电API，该API根据商店的IP地址返回商店的身份。这还将将应用程序的使用限制为内部网络。
无论哪种情况，员工都只能在身份验证身份验证到身份验证服务器时输入存储密码。
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.
我了解担忧，因为您需要安全性和可管理性之间的中间立场。目标是满足即时要求但也有良好的未来可能性的选择。
首选流量
代码流将是正确的选择，因为它具有最佳的灵活性。使用
未来的证明安全
长期考虑的事情是执行其中一个或两者的能力，可以通过各种方式完成：
代码流允许各种选择：
将您的当前用户标识转换为在代码流期间运行的自定义身份验证操作 - 您可以将其用作主要因素，也许是次要因素
，商店员工可以通过用户友好的设备登录。例如 webauthn键而不是密码
移动应用程序可以存储客户凭证，如果每个设备不同。在更高的安全设置中，这可能是强大的加密凭据。在
当然，您无需完成所有这些操作，但是使用代码流时，工具存在，并且添加更高级的安全性通常不需要任何代码更改。
初始推出
棘手的部分是设计初始推出而不会阻止问题。另一个选项可能涉及每个商店的2个用户帐户（一个具有管理员权限的用户帐户），并使用简单的密码。
当然，您还应该考虑威胁 - 例如，如果其中一位员工执行了恶意措施，如何跟踪用户。
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:
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.