Hello Manish,

In the 'client credentials' grant type the OAUTH Access Token is issued to the 'Client', specifically the OAUTH 2.0 client, which is distinct from the end user. Traditionally, the OAUTH 2.0 'Client' is an application working on the user's behalf to perform some task.

There are a few things to consider here. Are you using OAUTH at the Reverse Proxy tier in 'Authentication' mode ([oauth] oauth-auth = https) or in 'Authorization' mode ([oauth-eas] eas-enabled = true).

OAUTH Authentication mode actually validates the supplied Bearer token to the AAC module for verification and takes the received username and attempts to authenticate it against the ISAM LDAP repository. It is possible to have an 'external user' for users that do not exist in the repository.

OAUTH Authorizations mode, which is invoked by attaching an API Protection Definition in the ISAM object space (oauth-pop), validates the supplied Bearer token to either allow or deny the transaction to pass, but does not supply a Reverse Proxy authenticated session.

If you're looking to perform OAUTH Authentication then the 'client_id' needs to exist as a user in ISAM with the 'client_secret' as his password.

If your end goal is to get a token and then authenticate as the end user who is using the application which is the OAUTH Client then you are not using the correct grant type. Consider using 'Authorization Code' or 'Resource Owner Password Credentials' (ROPC/Username Password).

The 'Resource Owner' is the end user in the context of the OAUTH specification.
---
Aside from the above, the '/mga/sps/authsvc' endpoint is supposed to be unauthenticated and realistically if you're making an API call you'll want to use the '/mga/sps/apiauthsvc' endpoint instead as it returns a JSON response.

When OAUTH Authentication is enabled and the Reverse Proxy receives a bearer token it will attempt to validate that token against AAC regardless of whether the ACL on the resource allows for unauthenticated access.

Hello Manish,

In the 'client credentials' grant type the OAUTH Access Token is issued to the 'Client', specifically the OAUTH 2.0 client, which is distinct from the end user. Traditionally, the OAUTH 2.0 'Client' is an application working on the user's behalf to perform some task.

There are a few things to consider here. Are you using OAUTH at the Reverse Proxy tier in 'Authentication' mode ([oauth] oauth-auth = https) or in 'Authorization' mode ([oauth-eas] eas-enabled = true).

OAUTH Authentication mode actually validates the supplied Bearer token to the AAC module for verification and takes the received username and attempts to authenticate it against the ISAM LDAP repository. It is possible to have an 'external user' for users that do not exist in the repository.

OAUTH Authorizations mode, which is invoked by attaching an API Protection Definition in the ISAM object space (oauth-pop), validates the supplied Bearer token to either allow or deny the transaction to pass, but does not supply a Reverse Proxy authenticated session.

If you're looking to perform OAUTH Authentication then the 'client_id' needs to exist as a user in ISAM with the 'client_secret' as his password.

If your end goal is to get a token and then authenticate as the end user who is using the application which is the OAUTH Client then you are not using the correct grant type. Consider using 'Authorization Code' or 'Resource Owner Password Credentials' (ROPC/Username Password).

The 'Resource Owner' is the end user in the context of the OAUTH specification.
---
Aside from the above, the '/mga/sps/authsvc' endpoint is supposed to be unauthenticated and realistically if you're making an API call you'll want to use the '/mga/sps/apiauthsvc' endpoint instead as it returns a JSON response.

When OAUTH Authentication is enabled and the Reverse Proxy receives a bearer token it will attempt to validate that token against AAC regardless of whether the ACL on the resource allows for unauthenticated access.

Hello Manish,

In the 'client credentials' grant type the OAUTH Access Token is issued to the 'Client', specifically the OAUTH 2.0 client, which is distinct from the end user. Traditionally, the OAUTH 2.0 'Client' is an application working on the user's behalf to perform some task.

There are a few things to consider here. Are you using OAUTH at the Reverse Proxy tier in 'Authentication' mode ([oauth] oauth-auth = https) or in 'Authorization' mode ([oauth-eas] eas-enabled = true).

OAUTH Authentication mode actually validates the supplied Bearer token to the AAC module for verification and takes the received username and attempts to authenticate it against the ISAM LDAP repository. It is possible to have an 'external user' for users that do not exist in the repository.

OAUTH Authorizations mode, which is invoked by attaching an API Protection Definition in the ISAM object space (oauth-pop), validates the supplied Bearer token to either allow or deny the transaction to pass, but does not supply a Reverse Proxy authenticated session.

If you're looking to perform OAUTH Authentication then the 'client_id' needs to exist as a user in ISAM with the 'client_secret' as his password.

If your end goal is to get a token and then authenticate as the end user who is using the application which is the OAUTH Client then you are not using the correct grant type. Consider using 'Authorization Code' or 'Resource Owner Password Credentials' (ROPC/Username Password).

The 'Resource Owner' is the end user in the context of the OAUTH specification.
---
Aside from the above, the '/mga/sps/authsvc' endpoint is supposed to be unauthenticated and realistically if you're making an API call you'll want to use the '/mga/sps/apiauthsvc' endpoint instead as it returns a JSON response.

When OAUTH Authentication is enabled and the Reverse Proxy receives a bearer token it will attempt to validate that token against AAC regardless of whether the ACL on the resource allows for unauthenticated access.