Understanding e-Pragati RESTful API authentication methods

RESTful API authentication sits at the boundary between an incoming request and a protected service. It establishes whether a caller is who it claims to be, while authorisation decides which records or actions that caller may access. For teams exploring the e-Pragati platform’s RESTful API authentication methods, separating those two ideas prevents a valid login from being mistaken for broad permission. Citizen details, business registers and internal workflows can all sit behind that boundary.

Common RESTful patterns include API keys, OAuth 2.0 tokens, OpenID Connect sign-in, mutual TLS and signed requests. They are not interchangeable labels for one mechanism, and no single approach fits every service. A useful architecture decision considers the client type, data sensitivity, number of relying parties and burden placed on administrators. Descriptions of these patterns are practical reference material, not a declaration of officially supported e-Pragati features.

Australian conditions add useful nuance. Canberra hosts many Commonwealth agencies, but service delivery also involves state and territory administrations, local councils, contracted providers and SMEs with limited security capacity. Commonwealth agencies handling personal information generally apply the Privacy Act 1988 and Australian Privacy Principles; state and local bodies may operate under their own regimes. A casual “no worries” can settle who will chase a missing spreadsheet field in a joint project, but it should not settle who owns a digital credential.

The practical path is to map the request, identify the client, select a proof of identity, limit the permitted actions, and plan expiry, revocation and audit. Then test the failure behaviour as carefully as the successful path. Service-specific documentation and provider confirmation remain essential before storing real personal information or enabling production access.

Authentication and authorisation in context

Authentication answers who is calling; authorisation answers what the caller may do. A person may authenticate through an approved identity provider yet receive a token carrying only one workflow role. A scheduled job may authenticate with a workload identity and have no human session at all. If an API accepts an ordinary browser request, the design must also resist cross-site request forgery and token theft. These distinctions should appear in service diagrams, interface contracts and tender specifications.

Architecture governance helps prevent each integration from inventing its own interpretation. The background on enterprise architecture principles is useful here because identity, data ownership and interoperability need common architectural rules rather than isolated fixes. A reference model can define the identity provider, API gateway, consuming application, protected resource, audit service and administrative responsibilities. It can also record trust boundaries, such as a council system calling a state platform, without asserting that every deployment uses identical components.

A sound model separates the client registry from the API itself and keeps credentials out of application configuration wherever possible. Service owners decide what business capability an interface exposes; security teams decide how identity evidence is produced and protected; platform engineers enforce those decisions at runtime. This division matters in Australia’s mixed market, where a large agency, a regional council and a local software supplier may have different cloud arrangements and procurement constraints. Standard contracts can preserve consistency even when their operating models differ.

Common methods for RESTful interfaces

API keys and HTTP Basic authentication are simple starting points, but each carries a specific risk. A key acts as a shared secret between a client and a service. Basic authentication combines a username and password in a reversible encoding, which is not encryption, so it must travel only over correctly configured TLS. If retained for a narrowly scoped legacy interface, the key should be time-limited where feasible, stored as a hash, rotated regularly and revocable without disrupting unrelated clients.

OAuth 2.0 offers more flexible delegation. In the client-credentials pattern, one system obtains an access token for itself and presents that token as a bearer credential. Many deployments issue JSON Web Tokens (JWTs) carrying scopes, audience and a short expiry, while others use opaque tokens. For higher-assurance machine identities, a signed client assertion or mutual TLS can reduce reliance on a replayable shared secret. In a conceptual request, the client sends an authorization header containing a token issued for the intended API; the resource server checks its signature or introspection result before releasing data.

OpenID Connect adds an identity layer for cases involving a person. It typically complements OAuth 2.0 rather than replacing it: the identity token describes the authentication event, while the access token grants API permission. Public browser clients should use the authorisation-code flow with PKCE, and confidential clients should keep secrets on the server. Australian services may involve an approved identity arrangement such as Digital ID, but availability and suitability must be confirmed for the particular use case.

Mutual TLS authenticates both ends of a connection through certificates, binding a caller to a known workload. Signed requests add message-level integrity through a timestamp, nonce and keyed HMAC signature, which can help prevent replay. Neither mechanism grants business permissions automatically, so authorisation still needs explicit rules. Consumer services show the same distinction: a public booking interface in the mould of Two Belles Fitness may use delegated user access for a profile, while its back-office scheduler would need a separate confidential-client credential.

Choosing an access pattern that fits

Select the pattern from the relationship, not from protocol fashion. A workforce application acting for a signed-in employee may need delegated user access. A service-to-service exchange usually suits OAuth 2.0 client credentials, while a tightly controlled back-office link may justify mutual TLS. An API key can remain sensible for a low-risk internal service, provided its handling matches its value. For Australian councils and smaller suppliers, a proportionate control often beats an expensive identity platform that cannot be maintained.

Scopes should name business capabilities, such as viewing a licence record or submitting a workflow, rather than broad administrative powers. Role-based controls can handle stable duties; attribute-based controls can apply rules such as organisation, location and record ownership. Service accounts need the same scrutiny because delegated credentials can create a confused deputy. Every endpoint should decide whether an authenticated caller also has entitlement to the specific record, and default denial is safer than assuming access.

Human-facing design belongs in this discussion because an approval is an authorisation event. A consent screen should explain the requesting service, the data, the purpose and the duration in plain English. Someone who prefers poetry online between meetings should not need legal expertise to understand an approval. For personal information, teams should document the purpose, apply minimisation, and assess privacy impacts before adding fields or automated decision-making.

Protecting credentials and API traffic

Credentials fail through ordinary operational mistakes as well as attacks. They end up in source control, chat messages, support tickets, exported spreadsheets and developer workstations. Australian government procurement often expects controlled key management, yet a password manager alone does not solve workload secrets. Teams should use an approved secrets manager or vault, issue credentials to a workload identity, restrict retrieval and log access. Where a program supports a small agency, cybersecurity framework guidance can support a staged response rather than a rushed purchase.

Transport security is only one layer. Every request should use current TLS, certificates should be renewed automatically, and obsolete protocols should be rejected. APIs need rate limits, replay protection and consistent handling of expired or revoked tokens. Token audiences should be narrow, so a token issued for one API cannot be replayed against another. High-risk operations may require stronger client proof or step-up authorisation, while validation errors must reveal enough to diagnose a fault without exposing sensitive information.

Auditability turns authentication controls into usable evidence. Logs should record the authenticated client, subject where relevant, scopes used, action, result, correlation identifier and timestamp, but never raw tokens or passwords. Australia’s privacy regulators expect governance around access to records, and incident playbooks need to cover credential misuse, not only malware. A team distributed across Sydney and Melbourne should also record timestamps consistently and retain context that survives staff changes or supplier exit.

From authentication decision to working access

Translate the chosen method into an operational record. Register the client, name an accountable owner, record its business purpose, list approved scopes, set token lifetimes, and define rotation, suspension and revocation triggers. Record whether the client is a public browser application, confidential server application or workload, because each has different secret-handling duties. Onboarding and offboarding procedures then treat access as lifecycle-managed rather than as a one-time configuration change.

Test the complete journey in a safe environment before production approval. Exercise missing credentials, invalid signatures, expired tokens, insufficient scopes, disabled accounts and revoked permissions. Confirm that responses distinguish authentication failure from authorisation failure, and that logs join the business transaction to its security events. Independent testing may include code review, dependency scanning and penetration testing. In public-sector delivery, acceptance evidence is often as important as the control itself because it demonstrates the control operates as documented.

Service-specific documentation must settle any uncertainty about actual endpoints, supported grants, token formats and client registration. Only the relevant provider can confirm that a particular e-Pragati interface supports a particular method. Teams that need clarification can contact the maintainers with the service name, client type, intended scope and lifecycle requirement. A precise enquiry produces a more useful answer than a general request to “turn on security”, and it helps maintainers distinguish reference guidance from an official product commitment.

Start the next integration with one low-sensitivity service, document its authentication and authorisation flow, and validate expiry, revocation and audit behaviour in a non-production environment. Use that pilot to shape the pattern for wider agency, council or supplier connections, then approve production access only after the credential owner, rotation test and audit evidence are in place. This creates a repeatable control without forcing every team into the same technical approach.