OAuth Authentication
Registering your App
Cisco next generation Cloud Collaboration APIs are secured using an industry-standard OAuth 2.0 Service. An application may utilize Cisco Cloud Collaboration service APIs on behalf of itself or an end user. OAuth 2.0 provides the mechanism for end users to authorize 3rd party access to services on their behalf without sharing their credentials (typically, a username and password) with the 3rd party.
Applications must register with the OAuth 2.0 service before they may interact with Cisco Collaboration APIs. Once an application has been registered it may utilize APIs using it’s client ID and secret to negotiate the OAuth 2.0 flows.
The Cisco OAuth 2.0 service provides the following benefits:
- Applications do not need to capture, store and replay user passwords
- Allows use of third party identity providers
- Allows use of practically any form of user authentication
- Streamlines integration with multiple services
Step 1: Register app using Cisco OAUth 2.0 Client Registration and Management system :
- Your work email address
- Company Name
- Application Name
- Application Description
- Application Type
- Redirect URL
- Service API Scopes
Next enter the required information to register your app with the Cisco OAuth 2.0 system. The OAuth 2.0 registration system will return an OAuth clientID and a clientSecret that your application will use to identify itself when requesting authorization.
You can then make use of the Registration and Management system to add additional owners for your application, un-register your application, update your application information, or generate a new application secret.
Step 2: Implement the appropriate Authorization Grant flow
The Cisco OAuth 2 Service supports standard authorization flows:
- authorization code grant
- SAML2 Bearer Assertion grant (extension to the OAuth2 protocol)
The authorization flow utilized must be appropriate to the application use case being implemented. The authorization code grant flow is utilized for all API calls that are on behalf of an end user. API calls on behalf of a partner or customer organization will utilize the SAML assertion grant flow.
Step 3: Application uses Access Token to call Service APIs
After the application has obtained an access token, it may send the access token in a service API call.
Access tokens are valid only for the scopes (set of operations) the application requests.
For example, if an application requests the audio service scopes on behalf of John Smith and is granted an access token, then the application will only be able to use the token to call APIs for John that are covered by the audio service scopes
Please read the developer documentation to understand how to properly gain and use Access Tokens.
