Identity & Access Mgt
Contactless Transactions in the World of “New Normal”
Developed on OpenID Connect CIBA (Client-Initiated Back-channel Authentication)
The world has been facing a tragic pandemic and forced to a global lockdown for months. With new normal of life, people are starting to adapt and though its ridiculous yet try to ‘Live with Corona’. What about transactions and payments — may be Cashless or Contactless be the new normal? Cashless transactions are already in practice. But how about going completely contactless transactions/payments?
This blog is divided into three phases. First one is to give a brief idea of the use case. Second one is to elaborate on the technology used behind; i.e. CIBA. Third, the implementation strategy as a CIAM solution.
1. Contactless Payments
Contactless payment is a secure payment method using a debit or credit card, smartcard, or another payment device by using RFID technology or Near-Field Communication(NFC). Contactless payment is considered a quick and easy way to pay since it doesn’t require consumers to input a PIN.
Current payment modes, cash or card mandates a contact point. But how about an NFC or RFID tagged card which you just tap over the Point-of-sales and just walk away. Your transaction is basically done. It is that simple. But it poses several questions !!
Is it feasible? And secure enough? Can not someone steal my card and pay? Do we have a standard that can assure security?
OpenID Connect Client Initiated Back-channel Authentication (CIBA) is an efficient and effective standard on which we can build a contactless transactions.
But anyone can just take my card and walk-through right?
No, That's the beauty. When you tap the NFC or RFID tagged card on a Point-of-Sales, a mobile app configured for this purpose will be notified and unless you authenticate the transaction, the payment will not be made. This provides the owner of the card and the mobile app a seamless experience. It might be the case that you use the card and you authenticate or else you can allow your dad, mom wife, or children to do the shopping, tap it against a POS(Point-of-Sales) and you authenticate to pay from a mobile device.
Following is a brief use case of how contactless authentication based on CIBA is built. Consider that “ExampleBank” has provided the support of contactless transaction (“C-Pay”) that to be used with their card “CPayCards” which is NFC tagged.
- Bob has registered for the “C-Pay” service. He is provided with a payment card (NFC tagged). The “CPayCards” has the details of Bob-his name, mobile number, email, and some other bank details.
- We require an identity server - take the WSO2 Identity server for an example.
- Then the user will tap his card over the CPay Readers(Consumption Device). And the Salesperson will add the necessary transaction details (bill amount, transaction id, and some other information).
- Now when his card is tapped against the system(CPay Readers), the CPay Reader initiates a request to the Authorization Server (WSO2 Identity Server).
- Note that Bob has to download an app (C-Pay app). Bob has already logged into the app using his email and credentials and credit card details are annexed, so that amount for the transaction can be directly deducted from his bank account or credit card.
- Authorization server, upon receiving the request to initiate the transaction, wants the end-user to authenticate the transaction. So Authorization Server requests Bob to authenticate the transaction. So it sends an authentication consent request.
- Upon seeing the request on his C-Pay app on his phone(Authentication Device), Bob authenticates the request(ensure that transaction is initiated by himself)and approves(authenticates-provides the consent) the transaction.
- Upon receiving the authentication and the consent, the authorization server admits the client(consumption device) to initiate the transaction with the bank by passing down access and identity token.
- The client initiates the transaction and a happy customer with a completely contact-free transaction.
To better understand this we require to understand CIBA which provides the background for such secured mode of transaction.
CIBA eases out decoupling of authentication device from a consumption device; consumption device and authentication device.
CIBA is so Cool, because no such annoying redirections and highly secured as no such browser redirections involved.
2. Client-Initiated Back-channel Authentication (CIBA)
CIBA is developed as a solution to address issues existing and to capture events that were not handled by OpenID Connect. Out of those issues addressed, the following are vital and of great impact.
- Browser redirects: In OpenID Connect authentication flows it is very pressing that it always needs browser redirects at least authorize code flow and implicit flow. These browser redirects are vulnerable to attacks. And devices that have no browsers [POS systems, IoT devices] are unable to subscribe to these flows.
- Client initiated authentication flow (without user interaction): In all of the other flows, user interaction at the consumption device is a necessity. But CIBA doesn’t rely on user interaction at consumption device to initiate the flow. The client itself can initiate the authentication flow for the user of its own interest with or without getting a user identity from the end-user. But the user interaction at the authentication endpoint is essential to continue the flow.
Exciting Features CIBA incorporates some exciting security practices.
- Decoupled Authentication: As the name suggests the authentication process is decoupled. In most of the systems, the service consumption and authentication is in the same device. For example, consider a mobile application. When you want to get a service you are requested to provide your credentials on the same mobile phone and you then get authenticated. Here mobile phone is the consumption as well as an authentication device.
Before introducing the flow it is better to introduce key components of the CIBA flow.
- Authentication device: Used by the end-user to authenticate himself to the Authorization Server. (Eg. Mobile Phone)
- Consumption device: The device that is engineered for end-users to receive services. (Eg. Point-of-Sales)
- Authorization Server: An Authorization Server issues tokens to client applications.
Following is the abstract authentication flow for CIBA.
- Step 1: The user wants a service from a Consumption device (Eg: A point of sales). He invokes the transaction by providing his identity.
- Step 2: The consumption device started the authentication process with an “Authentication request” to the Authorization Server.
- Step 3: On receiving the request, the Authorization server sends an auth_req_id to the consumption device with the response.
This auth_req_id is used for further transactions, callbacks and it is a critical element in request-response validation.
- Step 4: Now the authorization server initiates communication with the end-user and requests credentials and then his consent to approve the consumption device to process the request.
- Step 5: Authentication Device sends(pops up) a request for credentials and consent for the request made at Authorization Server.
- Step 6: End User provides consent and credentials.
- Step 7: The server sends a notification to the consumption device once it receives consent and credentials.
- Step 8: Now Client requests the ID and Access token.
- Step 9: And the server sends the token.
2.1 EndPoints
We need to be aware of three Endpoints when we are dealing with them. Two of them are mandatory for all flow patterns (reside on the authorization server-side) and the other is optional in regard to the flow and resides on the client-side. CIBA Endpoint is a mandatory Endpoint that accepts CIBA Authentication requests from client app of consumption device. And in return send a CIBA Authentication response with required parameters or an error response if the request is not valid. Token Endpoint is also a mandatory Endpoint that accepts the token request from the client app of the consumption device. And in return respond with tokens or error response if the request is not valid (ie; required parameters missing, auth_req_id expired and etc). Client Notification endpoint is an optional EndPoint that can be set by the client himself. This endpoint will be pinged by the Authorization Server with a notification after successful communication with the end-user at the authentication device. It is optional and mandatory only if authentication flow follows Ping mode and Notification patterns are used.
2.2 Modes of Token Request
Poll mode beings with the authorization server sending an authentication request to the authentication device previously registered by the Client with a unique identifier sent by the Consumption device to the CIBA endpoint. Once the credentials and consents are received tokens will be available to be issued. The client will continuously poll the Token Endpoint to get a response token. If the token is available tokens will be provided. Else error response will be issued. Ping mode is when the authorization server will send an authentication request to the authentication device previously registered by the Client with a unique identifier sent by the Consumption device to the CIBA endpoint. Once the credentials and consents are received a notification is sent to the Client notification endpoint about the availability of tokens. Upon receipt of the notification, the Client makes a request to the token endpoint to obtain the tokens. Push Mode is when the authorization server will send an authentication request to the authentication device previously registered by the Client. Once the credentials and consents are received token will be ready and the Authorization server sends a notification (Step 7 in Fig.4.) to the Consumption device, inclusive of ID and access token.
2.3 CIBA Authentication Flow — Poll Mode
Now, with the basic understanding of the endpoints, authentication flow, and the token request modes, taking POLL Mode as an example lets have a deep understanding of important steps.
2.3.1 The Authentication Request
Authentication Request is initiated by the client (And that’s why it is Client-Initiated Back-channel Authentication). The client needs to inform the authorization server about for whom it is requesting the authentication. So it is mandatory that there should be some user identity from the Consumption device for which it can request, Access, and ID token. There are three ways for a consumption device to add user identity. login_hint,login_hint_token, id_token_hint can be a used. login_hint is a hint to the Authorization server about the user for whom the Authentication flow is initiated. The value may be an email address, phone number, account number, username, etc., which identifies the end-user to the OP. The value may be directly collected from the user by the Client just before the CIBA Authentication request or can be obtained in other ways. login_hint is simple to understand and implement though login_hint_token and id_token_hint can provide improved security. login_hint_token is a token with user details and id_token_hint is sending a previously received ID Token as a hint. Do not worry if you don't understand it deeply. Just consider these hints provide information about the user to the Authorization Server.
Scope is a required parameter. “openID” is the mandatory value (Eg. { “Scope” : “openid%20email%20example-scope”}). ACR values is an optional parameter. Acr stands for Authentication Context Class Reference. Indicate whether authentication happens successfully or not. If '0' - Did not meet the authentication requirements successfully. Highly recommended that if the request has this, let the response has this too. User-code too is an optional parameter which is a pin/password only known for the end-user which is used to authorize the Authentication Request preventing random clients or users initiate authentication requests for the legitimate user who is unaware and has to deny the access. The binding_message, an optional parameter is a human-readable message displayed on both Authentication and Consumption devices to interlock. Requested expiry an optional parameter is a positive integer value that allows the client to request 'expires_in' value for auth_req_id.
POST http://localhost:8080/CIBAEndPoint HTTP/1.1
Host:http://localhost:8080
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW{
"scope" : "openid%20email%20example-scope"
"binding_message: "W4SCT"
"login_hint":"A@examplebank.com"
}The CIBA specification recommends signed authentication requests which can be sent as the request parameter. And for simplicity, we will not be going through them here. You can check this blog for more details.
2.3.2 Authentication Response
Once the request is successfully validated, the Authorization server responds with “200 OK” indicating that the authorization request has been accepted. And Authorization server sends an Authorization response. If failed invalidation, the response message is sent with error_message and error_code. We can see them later in detail. auth_req_id is a required parameter. It has to be a unique identifier for the Authentication request made. expires_in is also a mandated parameter. It is a positive long value representing seconds. It marks the expiry time of auth_req_id. And if the auth_req_id expired, has to respond with an error response. Interval is an optional parameter. It is mandatory only for ping/poll token request modes. It is a positive long value representing seconds which denotes the polling frequency.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store{
"auth_req_id”:”702552be-f0ef-4ca0–9f66-c766e9525e63",
”interval”:2,
”expires_in”:3600
}2.3.3 Communication
Now OP(OpenId provider-Authorization server) communicates with the end-user. This communication step is out of the scope of the specification of CIBA. We need to choose a better option to implement.
2.3.4 Token Request
For Ping one it receives Authentication device requests for Token with confirmation with the reception of correct auth_req_id back to the Authentication device. For Push, the Token is sent once the Authorization server receives the provision of consent and credentials. For Poll Token mode Authentication device can continue to poll for a token once it receives Authentication response with auth_req_id and poll till it expires(will result in an error if it tries to poll again once it receives token). grant_type is a mandatory parameter and the value should beopenid:params:grant-type:ciba . auth_req_id is a mandatory parameter that is used to validate the request.
POST http://localhost:8080/TokenEndPoint
Host:http://localhost:8080
Content-Type: application/json
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW{
"grant_type":"urn:openid:params:grant-type:ciba"
"auth_req_id":"702552be-f0ef-4ca0–9f66-c766e9525e63"
}2.3.5 Token Response
Token response too, common for ping and poll. Token Response usually adds an access token, ID token, and optionally a refresh token. It also includes expires_in parameter to mark the expiry time of the token provided.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store{
“access_token”: “G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN”,
“token_type”: “Bearer”,
“refresh_token”: “4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16”,
“expires_in”: 3600,
“id_token”: "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE2NzcyNiJ9.eyJpc3MiOiJo
dHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsInN1YiI6IjI0ODI4OTc2MTAwMSIsImF1ZCI6InM2QmhkUmtxdDMiLCJlbWFpbCI6ImphbmVkb2VAZXhhbXBsZS5jb20iLCJleHAiOjE1Mzc4MTk4MDMsImlhdCI6MTUzNzgxOTUwM30.aVq83mdy72ddIFVJLjlNBX5JHbjmwK-Sn9Mir-blesfYMceIOw6u4GOrO_ZroDnnbJXNKWAg_dxVynv
MHnk3uJc46feaRIL4zfHf6Anbf5_TbgMaVO8iczD16A5gNjSD7yenT5fslrrW-NU
_vtmi0s1puoM4EmSaPXCR19vRJyWuStJiRHK5yc3BtBlQ2xwxH1iNP49rGAQe_LH
fW1G74NY5DaPv-V23JXDNEIUTY-jT-NbbtNHAxnhNPyn8kcO2WOoeIwANO9BfLF1
EFWtjGPPMj6kDVrikec47yK86HArGvsIIwk1uExynJIv_tgZGE0eZI7MtVb2UlCwDQrVlg"”
}3. Contactless Payment Strategy
In this section, let's dive deep into details of how a service provider can provide this feature as a customer IAM solution. Consider ExampleBank is willing to provide this feature and develop a CIAM solution upon this. First and foremost the bank should possess its own authorization server. There are various Identity providers and it is noteworthy to mention that there are open source IAM providers as well.
- Configure an Identity Provider (Authorization Server) and Service Provider(client app)
The very first is to configure the Identity server(or authorization server) to support this feature (Consider the Identity Server provider is capable of this.) The bank should register the service Provider (Eg.- CPay). The bank should create user accounts in the Identity Server(Authorization Server) for the relevant Service Provider or allow the user to register themselves (many IAM providers support this). When the users are registered, a map for their identity should be created. That is what will be emailed, mobile app SDK, or phone number through which Authorization server can communicate with end-user. Let's take that users are registered with an email, mobile app SDK, and notified in two of these modes.
2. Card and Necessary details
The bank should issue the NFC tagged cards so that they can be tagged on NFC readers at malls(Eg: CPay Readers). Once the transaction details are read from NFC tagged CPayCards, the CPay Readers at malls should initiate the Flow with the transaction details and all the necessary fields necessitated by Authentication Request.
3. Authentication request & response
Now the shop owner feeds necessary transaction details and the customer can see it from a display and after checking the details, he can tap his CPay card over CPay Readers.
This will invoke the authentication request from CPay Readers to the Authorization Server. Transaction_details can be added as an additional parameter that just carries necessary payment details that to be transferred to the authentication details and pretty sure that Authorization servers should adopt such additional parameters for CIAM use cases (Consider they accept Transaction_details parameter in AuthenticationRequest to carry necessary payment details.
4. Request validation & Communication
The authorization server validates the request, responds back with auth_req_id to the CPay Readers. Internally authorization server would check whether the user mentioned in login_hint exists and start communicating with him. Here there are two modes of communication. Since the user pertaining to `A@examplebank.com` has an email and a mobile app, the authorization server pushes a notification to both.
- For email: The authorization server will send an email with a magic link OTP so that when the end-user clicks it, he will be redirected to a credential and consent page as below. The user provides his credentials and consent.
2. For mobile app: Authorization server will push a notification to the mobile app which is capable of reading the notification from the Server and interpret to the end-user saying a particular user (Eg. John Doe) is trying to initiate a transaction on his card and might include necessary transaction details and sometimes the binding message. The user provides his credentials and consent.
5. Token Request and response
Till the user provides consent or denies it, the system at the mall will be polling for the token with received auth_req_id. And till it receives the token, it will receive an error response saying to wait(continue to poll) till the response from the end-user at the authentication device. If the user approves the transaction with consent, the token will be issued and the CPay Readers will proceed with completing the transaction with the bank. Else if the user denies, the transaction will be invalidated and let go.
