Iddawc API documentation

Iddawc is a C library used to implement OAuth2/OIDC clients according to the OAuth2 RFC and the OpenID Connect Specs.

It's based on Ulfius library for the HTTP requests and response management and Rhonabwy library for the JOSE management.

Iddawc supports the following features:

• Loading openid-configuration endpoints and parsing the results
• Making auth requests using the given parameters (client_id, client_secret, redirect_uri, etc.) and parsing the result
• Making token requests using the given parameters (code, client_id, client_secret, redirect_uri, etc.) and parsing the result
• Making userinfo, token introspection, token revocation requests
• Parse responses, validate id_token
• Registering new clients using the register endpoint if any
• Sending signed and or encrypted requests in the auth and token endpoints
• Client TLS Authentication available
• Making Pushed Auth Requests
• Making Rich Auth Requests
• Adding claims to requests
• Sending DPoP proofs
• JWT Secured Authorization Response Mode
• End session and single-logout functionalities

Return values

Lots of functions in Rhonabwy library return an int value. The returned value can be one of the following:

#define I_OK                 0
#define I_ERROR              1
#define I_ERROR_PARAM        2
#define I_ERROR_MEMORY       3
#define I_ERROR_UNAUTHORIZED 4
#define I_ERROR_SERVER       5

If a function is successful, it will return I_OK (0), otherwise an error code is returned.

Global init and close

It's recommended to use i_global_init and i_global_close at the beginning and at the end of your program to initialize and cleanup internal values and settings. This will make outgoing requests faster, especially if you use lots of them, and dispatch your memory allocation functions in curl and Jansson if you changed them. These functions are NOT thread-safe, so you must use them in a single thread context.

int i_global_init();
 
void i_global_close();

Log messages

Usually, a log message is displayed to explain more specifically what happened on error. The log manager used is Yder. You can enable Yder log messages on the console with the following command at the beginning of your program:

int main() {
  y_init_logs("Iddawc", Y_LOG_MODE_CONSOLE, Y_LOG_LEVEL_DEBUG, NULL, "Starting Iddawc client program");
  
  // Do your code here
  
  y_close_logs();
}

Example of an error log message:

2020-04-05T16:14:31 - Iddawc: i_run_auth_request - Unsupported auth_method

Go to Yder API Documentation for more details.

Core functions and struct _i_session * variables

Iddawc is based in the struct _i_session to store all the required parameters and results to work. You must use the init and clean functions before using a struct _i_session * and after finishing using it.

 
int i_init_session(struct _i_session * i_session);
 
void i_clean_session(struct _i_session * i_session);

Get or set properties

To set or get parameters stored in the struct _i_session *, you must use the appropriate function

 
int i_set_response_type(struct _i_session * i_session, uint i_value);
 
int i_set_result(struct _i_session * i_session, uint i_value);
 
int i_set_int_parameter(struct _i_session * i_session, i_option option, uint i_value);
 
int i_set_str_parameter(struct _i_session * i_session, i_option option, const char * s_value);
 
int i_set_additional_parameter(struct _i_session * i_session, const char * s_key, const char * s_value);
 
int i_set_additional_response(struct _i_session * i_session, const char * s_key, const char * s_value);
 
uint i_get_response_type(struct _i_session * i_session);
 
uint i_get_result(struct _i_session * i_session);
 
uint i_get_int_parameter(struct _i_session * i_session, i_option option);
 
const char * i_get_str_parameter(struct _i_session * i_session, i_option option);
 
const char * i_get_additional_parameter(struct _i_session * i_session, const char * s_key);
 
const char * i_get_additional_response(struct _i_session * i_session, const char * s_key);
 
int i_set_rich_authorization_request(struct _i_session * i_session, const char * type, const char * value);
 
int i_remove_rich_authorization_request(struct _i_session * i_session, const char * type);
 
char * i_get_rich_authorization_request(struct _i_session * i_session, const char * type);
 
int i_set_parameter_list(struct _i_session * i_session, ...);

Import or export sessions

Iddawc supports importing or exporting struct _i_session *. The export format is JSON. Be careful, the JSON output is unsecured and contains all secrets and tokens without encryption!

You can import and export either in json_t * or char *, the char * format is a JSON stringified.

 
json_t * i_export_session_json_t(struct _i_session * i_session);
 
int i_import_session_json_t(struct _i_session * i_session, json_t * j_import);
 
char * i_export_session_str(struct _i_session * i_session);
 
int i_import_session_str(struct _i_session * i_session, const char * str_import);

Run OAuth2 or OIDC requests

Finally, to run OAuth2 or OIDC requests, you must use the dedicated functions using the initialized and set struct _i_session * and some additional parameters if required.

Load openid-config

When available, you can load the Openid Config endpoint. This will parse the result and fill the struct _i_session * parameters with all the required results (auth endpoint, public keys, signature algorithms, etc.). Using this function required to have set the property I_OPT_OPENID_CONFIG_ENDPOINT.

 
int i_get_openid_config(struct _i_session * i_session);

Build and run auth request and parse results

The function i_build_auth_url_get can be used to build the full auth request with all the parameters in the URL query for a GET request.

 
int i_build_auth_url_get(struct _i_session * i_session);

The function i_run_auth_request builds the full auth requests and executes it. If the OAuth2 server answers with a successful response, the response will be parsed in the session properties. Otherwise, the redirect_to value and the errors if any will be parsed and made available in the session properties.

 
int i_run_auth_request(struct _i_session * i_session);

If the auth request is executed by an external program such as the browser, you can parse the redirect_to response afterwards using this function. You must set the I_OPT_REDIRECT_TO.

 
int i_parse_redirect_to(struct _i_session * i_session);

Build and run device authorization requests and parse results

If you need to run a device authorization request, you need to use the response type I_RESPONSE_TYPE_DEVICE_CODE and use the function i_run_device_auth_request, the parameter I_OPT_DEVICE_AUTHORIZATION_ENDPOINT must be set. On success, the parameters I_OPT_DEVICE_AUTH_CODE, I_OPT_DEVICE_AUTH_USER_CODE, I_OPT_DEVICE_AUTH_VERIFICATION_URI, I_OPT_DEVICE_AUTH_VERIFICATION_URI_COMPLETE, I_OPT_DEVICE_AUTH_EXPIRES_IN and I_OPT_DEVICE_AUTH_INTERVAL will be set. After that, you'll need to run i_run_token_request (see below) every few seconds until you get a success or a definitive error.

 
int i_run_device_auth_request(struct _i_session * i_session);

Build and run pushed authorization requests and parse results

To run a device authorization request, you need to use the function i_run_par_request, and the other parameters as if the request was a normal auth request (response_type, client_id, scope, redirect_uri, authenticaiton type, etc.).

On success, the parameters I_OPT_PUSHED_AUTH_REQ_URI and I_OPT_PUSHED_AUTH_REQ_EXPIRES_IN will be automatically set. Then the function i_build_auth_url_get will build an auth url using the request_uri and client_id parameters only.

 
int i_run_par_request(struct _i_session * i_session);

Build and run token requests and parse results

To execute a request in the token endpoint, get a refresh token from a code or refresh a token,

 
int i_run_token_request(struct _i_session * i_session);

Note: By default, token endpoint authentication method is I_TOKEN_AUTH_METHOD_NONE. If your client needs to be authenticated, you must specify the desired method by setting the I_OPT_TOKEN_METHOD with one of the following values:

• I_TOKEN_AUTH_METHOD_SECRET_BASIC: HTTP Basic Authentication
• I_TOKEN_AUTH_METHOD_SECRET_POST: Secret Post Authentication
• I_TOKEN_AUTH_METHOD_TLS_CERTIFICATE: MTLS authentication
• I_TOKEN_AUTH_METHOD_JWT_SIGN_SECRET: Client Assertion in JWT format signed with the client secret
• I_TOKEN_AUTH_METHOD_JWT_SIGN_PRIVKEY: Client Assertion in JWT format signed with the client private key
• I_TOKEN_AUTH_METHOD_JWT_ENCRYPT_SECRET: Client Assertion in JWT format encrypted using the client secret or a client symmetric stored in the client_jwks parameter
• I_TOKEN_AUTH_METHOD_JWT_ENCRYPT_PUBKEY: Client Assertion in JWT format encrypted using the AS public key

The values I_TOKEN_AUTH_METHOD_JWT_ENCRYPT_SECRET and I_TOKEN_AUTH_METHOD_JWT_ENCRYPT_PUBKEY must be combined with the values I_TOKEN_AUTH_METHOD_JWT_SIGN_SECRET or I_TOKEN_AUTH_METHOD_JWT_SIGN_PRIVKEY.

Verify an id_token

If the auth or token endpoints returns an id_token, this one will be parsed, the signature will be verified and the content will be validated to make sure the id_token is valid.

You can also manually validate an id_token using the dedicated function. The property I_OPT_ID_TOKEN and the public key property must be set.

When an id_token is validated, its claims are available in the property json_t * struct _i_session.id_token_payload.

 
int i_verify_id_token(struct _i_session * i_session);

Verify an access_token

If the access_token is a JWT, you can use the function i_verify_jwt_access_token to verify its signature and content. The access token must use the format specified in the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens standard.

The function will verify the claims iss, iat and aud.

When an access_token is validated, its claims are available in the property json_t * struct _i_session.access_token_payload.

 
int i_verify_jwt_access_token(struct _i_session * i_session, const char * aud);

If your Authorization Server provides JWT Access Tokens but not strictly according to the RFC, you can disable or enable the following JWT AT checks by (un)setting the following flags to the int property I_OPT_OPENID_CONFIG_STRICT:

• I_STRICT_JWT_AT_SIGNATURE: verify JWT AT signature
• I_STRICT_JWT_AT_HEADER_TYP: verify JWT AT header typ to be 'jwt+at' or 'application/jwt+at'
• I_STRICT_JWT_AT_CLAIM: verify mandatory other claims (iss, iat, etc.)

// Example setting to verify the access token signature and the claims, but not the `typ` header
i_set_int_parameter(i_session, I_OPT_OPENID_CONFIG_STRICT, I_STRICT_JWT_AT_SIGNATURE|I_STRICT_JWT_AT_CLAIM); 
 
if (i_verify_jwt_access_token(i_session, NULL) != I_OK) {
  // Error in token validation
}

Load userinfo

If an access_token is available, you can make a request to the userinfo endpoint to get information about the user.

The function i_load_userinfo_custom is a more advanced userinfo request where you can specify query or header parameters, to request more claims or the result as a signed JWT.

 
int i_get_userinfo(struct _i_session * i_session, int get_jwt);
 
int i_get_userinfo_custom(struct _i_session * i_session, const char * http_method, struct _u_map * additional_query, struct _u_map * additional_headers);

Introspect or revoke tokens

To execute introspection or revocation requests, you must set the session property I_OPT_TOKEN_TARGET and I_OPT_TOKEN_TARGET_TYPE_HINT if required.

 
int i_introspect_token(struct _i_session * i_session, json_t ** j_result);
 
int i_revoke_token(struct _i_session * i_session);

Register new clients

You can register a new client using this dedicated functions.

You may have to set a I_OPT_ACCESS_TOKEN property, depending on the server configuration. If update_session is true and the registration is successful, the properties I_OPT_CLIENT_ID and I_OPT_CLIENT_SECRET will be set to the session, and the first redirect_to entry will be used as I_OPT_REDIRECT_TO value.

 
int i_register_client(struct _i_session * i_session, json_t * j_parameters, int update_session, json_t ** j_result);

Manage clients registration

You can manage a client registration by changing its metadata or get the client registration metadata. These functions will use the access_token in the session if one is set.

 
int i_manage_registration_client(struct _i_session * i_session, json_t * j_parameters, int update_session, json_t ** j_result);
 
int i_get_registration_client(struct _i_session * i_session, json_t ** j_result);

Generate a DPoP token

You can use your client's private key parameters to generate a DPoP token. If you set the session property I_OPT_USE_DPOP to true, the functions i_run_device_auth_request, i_run_par_request, i_get_userinfo_custom, i_get_userinfo, i_run_token_request, i_revoke_token, i_get_token_introspection or i_perform_resource_service_request will add a DPoP header.

 
char * i_generate_dpop_token(struct _i_session * i_session, const char * htm, const char * htu, time_t iat, int add_ath);

Verify a DPoP proof

If you are using Iddawc in a Resource Service (RS), you can check the DPoP sent by the client using the function i_verify_dpop_proof. The parameter const char * access_token is mandatory to comply with DPoP Definition, Draft 04.

 
int i_verify_dpop_proof(const char * dpop_header, const char * htm, const char * htu, time_t max_iat, const char * jkt, const char * access_token);

DPoP nonce

When a request is sent to an Auth server or a Resource server, if the server can require a nonce in the DPoP to mitigate pre-generated DPoP tokens. If so, the server sends and error response with the status 400 for the AS and 401 for the RS, and the nonce required set int the HTTP response header "DPoP-Nonce". When the server sends such an error response, Iddawc will return a I_ERROR_PARAM value when relevant, but will set the nonce in the struct _i_session. It's up to the app using Iddawc to send another request by using the same function.

Example:

// First call to i_get_userinfo, without DPoP nonce
res = i_get_userinfo(i_session, 0);
if (res == I_ERROR_PARAM && i_get_str_parameter(i_session, I_OPT_DPOP_NONCE_RS) != NULL) {
  // Second call to i_get_userinfo, with the DPoP nonce set automatically
  res = i_get_userinfo(i_session, 0);
}

Perform a HTTP request to a Resource Service

This features uses Ulfius' ulfius_send_http_request function to proceed. This function requires at least a struct _u_request with all the request parameters.

Iddawc will add the access token previously obtained to the HTTP request using the Bearer usage specified.

If the access token is expired, Iddawc will attempt to refresh the token.

If specified, Iddawc will generate and add a DPoP token in the request using the request parameters.

 
int i_perform_resource_service_request(struct _i_session * i_session, struct _u_request * http_request, struct _u_response * http_response, int refresh_if_expired, int bearer_type, int use_dpop, time_t dpop_iat);

Here is an example of how to use i_perform_resource_service_request:

struct _i_session i_session;
struct _u_request req;
struct _u_response resp;
json_t * j_resp;
 
i_init_session(&i_session);
/*
 * All the process to get an access token is hidden, this example considers the _i_session has an access token
 */
ulfius_init_request(&req);
ulfius_init_response(&resp);
 
ulfius_set_request_properties(&req, U_OPT_HTTP_VERB, "GET", U_OPT_HTTP_URL, "https://resource.tld/object", U_OPT_NONE);
 
if (i_perform_resource_service_request(&i_session, &req, &resp, 1, I_BEARER_TYPE_HEADER, 1) == I_OK && resp.status == 200) {
  // j_resp contains the JSON response of the protected resource
  j_resp = ulfius_get_json_body_response(&resp, NULL);
}
 
i_clean_session(&i_session);
ulfius_clean_request(&req);
ulfius_clean_response(&resp);
json_decref(j_resp);

CIBA Requests

Iddawc can run CIBA requests as defined in the documentation OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0.

 
int i_run_ciba_request(struct _i_session * i_session);

Example of using i_run_ciba_request:

struct _i_session i_session;
i_init_session(&i_session);
i_set_parameter_list(&i_session, I_OPT_RESPONSE_TYPE, I_RESPONSE_TYPE_CIBA,
                                 I_OPT_OPENID_CONFIG_ENDPOINT, "https://as.tld/.well-known/openid-configuration",
                                 I_OPT_CLIENT_ID, "client",
                                 I_OPT_CLIENT_SECRET, "secret",
                                 I_OPT_AUTH_METHOD, I_TOKEN_AUTH_METHOD_SECRET_BASIC,
                                 I_OPT_SCOPE, "openid",
                                 I_OPT_CIBA_LOGIN_HINT, "{\"username\":\"ciba\"}",
                                 I_OPT_CIBA_MODE, I_CIBA_MODE_POLL,
                                 I_OPT_CIBA_LOGIN_HINT_FORMAT, I_CIBA_LOGIN_HINT_FORMAT_JSON,
                                 I_OPT_NONE);
 
i_get_openid_config(&i_session); // get CIBA endpoint
i_run_ciba_request(&i_session); // run request and store auth_req_id
i_run_token_request(&i_session); // get access_token and refresh_token when the user has completed the authentication

Note that when using ping or push mode, Iddawc doesn't implement the client notification endpoint, its implementation and communication with iddawc's session will be yours to make.

End session

Iddawc provides 3 functions dedicated to end session capabilities: OpenID Connect Front-Channel Logout and OpenID Connect Back-Channel Logout.

 
char * i_build_end_session_url(struct _i_session * i_session);
 
int i_verify_end_session_backchannel_token(struct _i_session * i_session, const char * token);
 
int i_close_session(struct _i_session * i_session, const char * sid);

Even if Iddawc doesn't provide Front-Channel or Back-Channel logout endpoints, you can use the function i_verify_end_session_backchannel_token to verify an end_session backchannel token, and i_close_session to clean the current session.

Rich Authorization Requests

Iddawc supports OAuth 2.0 Rich Authorization Requests Draft 11. You can manage RAR types using the following functions:

 
int i_set_rich_authorization_request_json_t(struct _i_session * i_session, const char * type, json_t * j_value);
 
int i_set_rich_authorization_request_str(struct _i_session * i_session, const char * type, const char * value);
 
int i_remove_rich_authorization_request(struct _i_session * i_session, const char * type);
 
json_t * i_get_rich_authorization_request_json_t(struct _i_session * i_session, const char * type);
 
char * i_get_rich_authorization_request_str(struct _i_session * i_session, const char * type);

Then, when using the authentication functions (auth, device, ciba, par), the authorization_details parameter will be set accordingly.