When running a CA Access Gateway (SPS), when user request OIDC
Authentication, then if the Redirect URI has value
com.rcu.myrcuapp://callback, then the transaction fails and the json
error code shown up is :
{
"error": "invalid_grant",
"error_description": "Invalid Authorization code."
}
CA Access Gateway (SPS) 12.8 on Windows 2016;
Policy Server 12.8SP1 on Windows 2016;
JDK 1.8.0_231;
There's a limitation with Policy Server 12.8SP1. Custom URI won't work
for Native application, even if the flow is configured as Confidential
(which is not recommended by the international standards). To get
Native Apps integration, upgrade the Policy Server to at least
12.8SP2. Note that Policy Server 12.8SP1 will be out of support on
March 31, 2022 as per our EOL EOS matrix (1).
A Native Application client is not a Browser based client. In the
difference of the Browser based client, for the Native application,
the response includes a Location header based on the application name
in the redirect URI instead of http or https as mentioned in this page
(2).
Now, the difference between Confidential and Public application isn't
directly related to the Native Application or Web Browser
application. The difference between both relies on how the credentials
are retained (3).
The Confidential client secret can be used in the application, but
with the risk that someone decompiles the code from the app to get the
secret which is not considered as secure (4).
Upgrade CA Access Gateway (SPS), Policy Server, Policy Store data and
AdminUI to 12.8SP6 to solve this issue;
(1)
Symantec SiteMinder Release and Support Lifecycle Dates
| Product | Release | Service Pack/Genlevel | End of Service (EOS), |
| | | | End of Life (EOL) |
| | | | or Stabilization Date |
|------------------------------------------+---------+-----------------------+-----------------------|
| Symantec Site Minder (CA Single Sign-On) | 12.8 | 02 | June 30, 2022 |
| | | 01 | March 31, 2022 |
https://support.broadcom.com/external/content/release-announcements/CA-Single-Sign-On-Release-and-Support-Lifecycle-Dates/6562
(2)
Custom URL Scheme
When the authorization server sends the Location header intending to
redirect the user to myapp://callback#token=....,
the phone will launch the application and the app will be able to
resume the authorization process, parsing the access token from
the URL and storing it internally.
https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uris-native-apps/
(3)
Confidential applications
Confidential applications can hold credentials in a secure way
without exposing them to unauthorized parties. They require a
trusted backend server to store the secret(s).
Public applications
Public applications cannot hold credentials securely.
https://auth0.com/docs/configure/applications/confidential-public-apps#public-applications
(4)
OAuth for Native Apps
[...] native apps can't maintain a confidential client secret after the
developer registers one, as that would require that the developer
ship the secret in their binary distribution of the application. It
has been proven to be relatively easy to decompile and extract the
secret. As such, native apps must use an OAuth flow that does not
require a secret.
https://www.oauth.com/oauth2-servers/oauth-native-apps/