Authorizations (preview) for multiple API clients

Question

Hi, we have 2 questions about Authorizations (preview) , for design and login process.

Design

Our scenario
API Backend : Jira Cloud (OAuth 2.0 - Authorization Code flow)
API Client : team 1, team 2, team 3, etc

API use cases :
sample
team A creates tickets to Jira project A
team B update tickets to Jira project B

Each team holds their own client id/secret by registering an App on Jira to define API access scope.
The game rule here is similar to Azure App Registration, API permissions.

--
We've successfully try Authorizations (preview) in test account, it works to fire the Jira Cloud API via OAuth 2.0.
But when it comes to real case, say multiple API clients, not sure how to map the structure to the Authorizations (preview).

Two ideas in my mind, which one is the best practice for my scenario ?

Idea 1 :

One identity provider with multiple Authorizations.
It looks good , but it seems team1 and team2 cannot separate their client_id and client_secret.
How do team1 and team2 use their own client_id, client_secret here ?

--
Idea 2
Each team has their own identity provider and the client_id, client_secret can be separated.

If go this way, how do I setup the policy for provider-id and authorization-id ?
Perhaps API client should add provider-id and authorization-id in the request header and I dynamically fetch its value ?
Like this

--

Login process
It seems login process can only be triggered manually.

How do I let team1 and team2 to conduct this ?
Idea 1 : I grant APIM management plane access right to team1 , team2 , and they hit the button on their own
Idea 2 : team1, team2 give me their credential, then I manually hit the button on behalf of them.

Both processes are a bit not natural for me , perhaps there's 3rd way ?

Need your advice

Thank you

PS : Jira Cloud API reference : https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro#version

Answer 1

@Lily Thank you for reaching out to Microsoft Q&A and sorry for the delay in response.

• Since you use Authorization Code flow, client secret has to be on authorization provider level and hence you would need to create one authorization provider configuration for each team. If you use Client Credentials, you can have one authorization configuration with multiple authorizations (each client id/secret). Refer docs describing this and idea#2 is the approach for your scenario.
• Yes correct, use snippet referenced in docs (or screenshot above) to pull the values based on query parameters or change it to headers or use policy expressions in the sample and set the values based on a condition. Try and let me know if you face any issues.
• As described in docs, Authorization Code is bound to a user context, and hence need to follow "Login with Generic Oauth 2" button and complete the authorization workflow (Process flow for creating authorizations) for each team/user. Check out Techcommunity article that shares an example with detailed steps in setting up authorizations (unfortunately it doesn't have multiple authorization scenario)

I hope these answers help with your questions and feel free to add a comment if you have any other questions. We would be happy to assist you. Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community.