Basic Access Authentication (RFC 2617)
Overview
System Actors
client = the party sending the HTTP request. i.e. the API Client
server = the party receiving the HTTP request. i.e. the endpoint, either MGW’s or the User’s
system
The implementation of HTTP Header “Authorization” is for the following core reasons:
1. Prove the identity of the client / user-agent
When required by the server, all requests are verified against the values set in the Authorization header.The server MUST either allow or deny requests based on the validity of the submitted header value
The authorization mechanism DOES NOT address confidentiality of the HTTP request. The HTTP Requests, however, MAY be sent via a secure transport (i.e. HTTPS) to achieve confidentiality.
The header value is formatted as: AuthType Credential
Where:
AuthType MUST be set to “Basic “.
Credential MUST be set as the encoded credential.
The ClientIdentity and Password must be combined into a string, then encoded using RFC2045-MIME variant of Base64, except not limited to 76char/line.
The ClientIdentity and Password will be provisioned and assigned to you by your Account Manager.
Permanent Redirects (Status 301 / 308)
Overview
The Messaging Gateway server MAY return status 301 or 308 in scenarios such as:
1. moved URL
2. HTTP to HTTPS upgrade
Connection Handling
- The API Client user-agent SHOULD expect the presence of the ‘Location’ http response header, the
value of which is the new URL. - The API Client user-agent SHOULD follow the new URL and replay the complete preserved request
(POST method, complete headers/auth, intact body) to the new URL location. This allows for
graceful continuation of the request.
Setup Checklist
- API Clients MUST be configured to use the correct, up-to-date HTTPS-based URL endpoint of the
MGW server. This is to prevent unnecessary redirects (degrading performance in the process) and
ensures a secure connection between the client and the server.
Rate Limits (Sending MT)
Overview
The Messaging Gateway server MAY rate-limit the API Client user-agent based on the following:
Criteria | Scope | Defaults |
Unauthenticated requests | per IP-address | 50 reqs over 5mins period |
Mobile Number | Per Mobile Number (MT Document.to field) | 5 reqs ver 60s period |
API Account | Per API-Client Account | disabled by default |
Connection Handling
- The API Client user-agent MUST internally account for in-flight messages (i.e. awaiting responses)
and MUST ensure that the rate limits provisioned are not breached. - The API Client user-agent MAY retry the request after a delay/back-off.
- For persistent rate-limits issues, please escalate and contact support.