有关受Azure OAuth 2.0保护的api的实际问题 [英] Practical issues about Azure OAuth 2.0-protected api
问题描述
We are providing a web api that is protected with Azure OAuth 2.0. Our affilates will use this api and they each will get a clientid/client.
1)在已链接方案.为什么需要刷新令牌?如果令牌过期，他们的(Web)应用程序将仅使用其clientid和sclient secret发送新令牌?
1) In the linked scenario. Why would there be need for a refresh-token? if the token expires their (web)application would just send for a new token using their clientid and sclient secret?
2)我们有100多个会员.几乎所有这些用户都有相同的权限，但是我们仍然希望为每个人提供唯一的clientid/secret.我们实际上如何做到这一点?是唯一的在Azure Web门户中手动操作的方法吗?
2) We have 100+ affiliates. Almost all of them will have same permissons, but we still want to give everyone a unique clientid/secret. How do we practically do this? Is manually in azure web portal the only way?
推荐答案
1)在链接方案中.为什么需要刷新令牌?如果令牌过期，他们的(Web)应用程序将只使用其clientid和sclient secret发送新令牌吗?
1) In the linked scenario. Why would there be need for a refresh-token? if the token expires their (web)application would just send for a new token using their clientid and sclient secret?
如果客户端对您的API进行委托调用，则使用刷新令牌.在这种情况下，令牌还将包含当前登录用户的信息.当访问令牌过期时，客户端可以使用刷新令牌为您的API获取针对特定用户的API的新访问令牌(而不是重定向他们以再次登录以获取授权码等).
Refresh tokens are used if the client makes a delegated call to your API. In this case the token will contain the currently logged in user's info as well. The client can use the refresh token to get a new access token for your API for a specific user when the access token expires (instead of redirecting them to login again to get an authorization code etc.)
如果他们仅使用客户端凭据(id + secret)来调用您的API，那么将没有刷新令牌.
If they call your API purely using client credentials (id + secret) then there will not be a refresh token.
2)我们有100多个会员.几乎所有这些用户都有相同的权限，但是我们仍然希望为每个人提供唯一的clientid/secret.我们实际上如何做到这一点?是唯一的在Azure Web门户中手动操作的方法吗?
2) We have 100+ affiliates. Almost all of them will have same permissons, but we still want to give everyone a unique clientid/secret. How do we practically do this? Is manually in azure web portal the only way?
要获得每个会员的唯一客户ID，您必须为每个会员创建一个新的应用程序注册.您可以通过以下一种Graph API(Azure AD Graph或MS Graph)创建应用程序和服务主体来自动执行此过程:
To get a unique client id for each affiliate, you must create a new app registration for each of them. You can automate this process by creating the Application and Service Principal via one of the Graph APIs (Azure AD Graph or MS Graph):
- AAD图: https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#application-entity
- 质谱图:请注意，应用程序的MS Graph端点仍处于beta版本，不建议用于生产环境.这是支持Azure AD Graph API的少数情况之一.
Note the MS Graph endpoints for applications are still in beta and not recommended for production use. This is one of the very few cases where Azure AD Graph API is the supported case.
您将需要为每个会员创建一个应用程序(还要记住创建passwordCredential(秘密))，然后根据应用创建服务主体，然后向您的API授予服务主体权限.如果这些是应用程序权限，则必须创建appRoleAssignments.
You will need to create an Application for each affiliate (remember to create the passwordCredential (secret) as well), then create a Service Principal based on the Application, and then grant the Service Principal rights to your API. If these are application permissions, you will have to create appRoleAssignments.
这篇关于有关受Azure OAuth 2.0保护的api的实际问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
