客户端是资源所有者吗？
第一个决定点是需要访问资源的一方是否是一台机器。在机器对机器授权的情况下，客户端也是资源所有者，因此不需要最终用户授权。一个例子是使用API将信息导入数据库的cron作业。在本例中，cron作业是客户端和资源所有者，因为它保存客户端ID和客户端秘密，并使用它们从授权服务器获取访问令牌。
这种情况下通常使用Client Credentials Flow。
客户端是在服务器上执行的web应用程序吗？
如果你的客户端是一个单独运行的服务，那么Authorization Code Flow就是最好的。
使用此方法，客户端可以检索访问令牌，也可以检索刷新令牌。它被认为是最安全的选择，因为访问令牌直接传递给承载客户端的Web服务器，而不需要冒着暴露的风险经过用户的Web浏览器。
客户端是否完全信任用户凭据？
如果完全信任，那么Resource Owner Password Flow就是一个选择。
在这个流程中，最终用户被要求填写凭据(用户名/密码)，通常使用交互式表单。此信息被发送到后端，并从后端发送到Auth0。因此，必须绝对信任客户端提供这些信息。
这种形式只能用在 基于重定向的流的形式无法实现时。
客户端是单页应用程序吗？
如果客户端是单页应用程序(SPA)，这是使用JavaScript等脚本语言在浏览器中运行的应用程序，则有两个授予选项：Authorization Code Flow with PKCE和Implicit Flow。
在大多数情况下，我们建议在PKCE中使用授权代码流，因为访问令牌没有在客户端公开，而且这个流可以返回刷新令牌。
Single-Page App SDK为在Spas中使用PKCE实现授权代码流提供了高级API。Auth0 Single-Page App SDK
如果SPA不需要访问令牌，则可以使用表单POST的Implicit Flow。
客户端是本地/移动应用程序吗？
是的话就用Authorization Code Flow with PKCE
我有一个应用程序需要与不同的资源服务器对话。
如果单个应用程序需要针对不同资源服务器的访问令牌，则需要执行多个对/authority的调用(即对相同或不同授权流的多次执行)。每个授权将对受众使用不同的值，这将在流的末尾产生不同的访问令牌。参见：
OAuth 2.0: Audience Information Specification