As a part of authentication & authorization flow, I am interested in using Authorization Code Flow , similar to OpenId Connect Flow which uses the route of /authorize endpoint to obtain authorization code from authorization server. The authorization code received is then used to obtain set of access and refresh token from token request of /token with grant_type = authorization_code (one of the safest 3 legged OAuth 2.0 flow).
Sample request for OIDC specification would be like this : [source]
Hi @aakash! I’m actually working on an Authentication API Guide which will provide a complete overview of the available authentication workflows. It should be published by the end of the week, however I can provide some initial information here now.
Right now the only way you can receive a token is using the /token route with grant_type=password as described here: Building an API Call
This will let you get everything you need to work with the API for now.
Eventually, we will be enforcing the use of the OIDC workflow to first obtain an authorization code which you can then exchange for the bearer and refresh tokens. The only reason you can’t use it right now is that the client_id and redirect_uri have to already exist in our database, something that will eventually happen as part of the application registration process we are building. You will eventually be able to either make use of the Mitel Auth Portal (auth.mitel.io) or create your own equivalent using the available API routes.
Thank you @budd.renaud for quick response and letting me know about OIDC workflow plans. I did try the Postman library, used grant_type=password with /token to receive set of access token and refresh token. I also tried a couple of API’s like Users and Contacts. I will continue to look more of them such as subscription and presentities. However, in accordance with architecture and requirements it’s crucial to use Authorization code flow / OIDC flow for authentication and authorization integration to take place. Do you have timeline on when it will be ready ?
We do not have a timeline at this point, however I am going to start looking into the possibility of creating a generic client_id per account (in Sandbox only) that can be used during development. Once you go to formally deploy the app in the Public environment, there will be an application registration process which we are in the process of finalizing now. Once that’s ready the process will be documented on the Developer Portal and I will review it with you during one of our recurring meetings.