OSP provides a non-standard OAuth 2.0 endpoint for signing additional data that can be passed during the grant request. The URL of the sign endpoint is: https://<serverip>/osp/a/TOP/auth/oauth2/sign.
The sign endpoint helps to create a signed and encrypted data packet that can be used to supply data to other endpoints. For more information, see the Sign class documentation.
The only endpoint with which the signed data is currently used is the grant endpoint when it is used with the authorization code grant and implicit grant types.
The signed data can be used to supply one or both of the following:
Username: Supplying the username for a client application is useful when you already know the username. For example, Advanced Authentication uses OSP for authentication after Advanced Authentication has obtained the username.
Advanced Authentication chain: An Advanced Authentication server (5.6 or later) can be used to supply one or more additional authentication factors by authenticating with Advanced Authentication OAuth 2.0 for a user who is already authenticated. The username and name of the desired authentication chain containing the factor(s) is supplied.
You must be able to resolve username in an Advanced Authentication repository and you must configure the chain in the Advanced Authentication event for the OAuth 2.0 client used.
Submitting the Data
The sign endpoint is used by submitting a string value to the endpoint. The output is returned in a JSON structure.The output can be used with the grant endpoint with the parameters attribute.
You can accomplish OAuth 2.0 client authentication with HTTP Basic or Bearer authorization header value.
Request parameters
data (required): The data to be signed and encrypted.
The following JSON request object code is an example to sign an endpoint.
{ "username" : "< username >" "LoginParameters" : { "internal.osp.oidp.aa.chain-name" : "<chain name>" } }
where username is name of the user trying to authenticate and chain name is name of the chain configured in the Advanced Authentication server.
ttl (optional): The time-to-live period of the result data in milliseconds. If no value is supplied, then the default value of 30 seconds is used.
HTTP status codes
The following table describes the HTTP status codes.
|
HTTP Status Code |
Description |
|---|---|
|
200 |
The operation was successful. |
|
400 |
The operation was unsuccessful. Additional error information may be found in the response content. |
|
401 |
Client authentication missing or invalid. |
|
500 |
A server error occurred. |
The cause of the error can be determined from the additional error information found in the response content.
Response content
The response to a successful request is a serialized JSON object (XML is not currently supported). The data field is the signed and encrypted data to be used with another endpoint. The exp field is the expiration time of the data as defined by RFC 7519. For more information, see the Data tracker.
The following sample code in javascript is an example of the response content.
{ "data":"_TXNCmy8ocXUg3Hg7u1TmRRJ3-2JQHcv3XggLbzhX2l6TcM-11sfYlVatE6KIhP1.e1lJXX3Gj5UlFPoo03ig-4vczT2UtrAzbV4poyN592s~", "exp":1488210079}
NOTE:The web authentication does not query the LDAP directly for users. Web authentication routes the request to the Advanced Authentication server internally. Therefore, if the Advanced Authentication server can match the inbound username with an appropriate attribute in the LDAP server, it would be same as what Advanced Authentication provides.