< Back to Package Overview
Working with O-Auth2 Credentials
This article builds on concepts introduced in https://www.devconnectprogram.com/site/global/products_resources/avaya_client_sdk/programming_docs/current/android/communication/tech/working_credentials.gsp
O-Auth Basics
To fully appreciate o-Auth, readers should familiarize themselves with the O-Auth2 RFC rfc6749.
OAuth defines four roles:
resource owner
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an
end-user.
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
client
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
authorization server
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.
O-Auth Call Flows
Abstract o-Auth Protocol Flow
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| || Authorization |
| Client | | Server |
| || Resource |
| | | Server |
| |
O-Auth Token types
- Access token - The access token is used to for authentication and authorization to get access to the resources from the resource server. (AMM, AADS contacts). Access tokens are short lived.
- Refresh token - The refresh token normally is sent together with the access token. The refresh token is used to get a new access token, when the old one expires. Instead of the normal grant type, the client provides the refresh token, and receives a new access token. Using refresh tokens allows for having a short expiration time for access token to the resource server, and a long expiration time for access to the authorization server.
O-Auth Sessions
Once an O-Auth session is authenticated and authorized, the O-Auth session is independent to the credentials used to establish the O-Auth session. I.E. If as part of establishing the O-Auth session an enterprise password is required, the O-Auth session is not invalidated because the enterprise password becomes expired, or is changed.
O-Auth References
|Doc | Reference |
|--|--|
|O-Auth2 RFC |https://tools.ietf.org/html/rfc6749 |
Avaya AADS (IAM) O-Auth2 Solution
AADS
The AADS implements an OAuth2 authorization code flow that is customized for our Client SDK clients. In support of this flow, there are three new API endpoints:
- /acs/resources/authorize
- Initiates the OAuth2 flow
- /acs/resources/code
- Returns the Authorization code
- /acs/resources/token
- Returns an access and refresh token upon
While the OAuth2 flow is initiated from the AADS, the AADS itself is not an Identity Provider and instead relies on an embedded third party component called Keycloak for the token management and brokering to an external third party identity provider.
Keycloak
Keycloak is a third party open source component that implements a fully functional Identity Provider (IdP) that also includes support for federation and brokering to external third party IdPs. Keycloak has many capabilities and can thus be used in many different deployment scenarios. For more information see the latest AADS Administration and Provisioning guide.
Client SDK Clients
As the O-Auth service may redirect to a browser page provided by the O-Auth service or any of the services in the Identity Provider flow, the O-Auth and IdP interactions are the responsibility of the Application (not the Client SDK). The Client SDK supports accepting the bearer token in the CredentialChallenge Response (include API link here), and providing the CredentialChallenge feedback (success, response).
O-Auth Solution Call Flow
The flow below starts with the client requesting configuration from AADS, to illustrate the bootstrap flow. Any unauthorized request to AADS can initiate the same redirection flow, and your app is not required to support the AADS configuration service.
![O-Auth Solution Call Flow]()
Token Refresh & Token Expiration
The token expiration time is provided to the client in the JWT token. Your application shall set a timer to refresh the token ahead of token expiration, when the token is successfully retrieved from AADS or retrieved from persistent storage. Your client shall persist the first redirect URL from AADS, to facilitate the refresh token.
If supported, the URL to refresh the token is provided to the client in the token payload.If the app has not been launched in a while, the token may be expired.
![Token Refresh & Token Expiration]()
