Establishing who is calling: validating credentials or tokens, resolving the user, and making that identity available to the application. AuthorizationAuthorizationDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.SAP and community, unassessed decides what that identity may do; identity provisioningIdentity provisioningGetting users, groups and role assignments into every system that needs them, and out again when a person leaves, through provisioning jobs or SCIM APIs. Authentication answers who is calling one request; provisioning decides whether the user exists in that system at all.SAP only manages its lifecycle across systems.
Establishing who is calling — validating a token, resolving the user and their roles, and making that available for the rest of the request. Taking SAP Cloud Identity ServicesCloud Identity ServicesIdentity Authentication and Identity Provisioning as one tenant: the login, the user store or the federation to a corporate identity provider, and the provisioning of users into whatever sits behind it.sap official, btp as the identity interface for everything SAP makes it SAML 2 or OIDC against Identity Authentication rather than XSUAA alone, with the user lifecycle carried by SCIM 2 replication into each service. AuthorizationAuthorizationDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.SAP and community, unassessed is still designed per system after that, since an S/4HANA role and a BTP role collection are different objects.
@sap/cds Validates tokens and builds the security context for XSUAA and IAS, exposing the authenticated user to handlers as req.user.
com.sap.cds:cds-feature-identity The CAP Java feature that validates OAuth2 tokens from XSUAA and SAP Cloud Identity ServicesCloud Identity ServicesIdentity Authentication and Identity Provisioning as one tenant: the login, the user store or the federation to a corporate identity provider, and the provisioning of users into whatever sits behind it.sap official, btp and builds the request's security context from them.
com.sap.cds:cds-feature-xsuaa The CAP Java feature that validated XSUAA-issued JWTs, published up to 2.10.7 before CAP Java 3.0 removed it in favour of com.sap.cds:cds-feature-identity.
Not covered: It stops at the platform identity providers. Anything else — custom IdPs, API keys, machine-to-machine patterns outside BTP — is yours to build. capire's own overview says CAP cannot guarantee end-to-end product security across all application layers by default; the platform's transport security and the application's own code are outside it.
On BTP the concern splits three ways, and the pieces are not alternatives. SAP Authorization and Trust ManagementSAP Authorization and Trust Management serviceThe OAuth server behind a BTP application: issues the JWT the app checks, holds the scopes and role collections it checks against, and brokers trust to an identity provider. Bound, never installed.sap official, btp is the OAuth server that issues the JWT an application checks; Cloud Identity ServicesCloud Identity ServicesIdentity Authentication and Identity Provisioning as one tenant: the login, the user store or the federation to a corporate identity provider, and the provisioning of users into whatever sits behind it.sap official, btp is the login itself, the user store or the federation to a corporate identity provider behind it; and carrying that identity onward, to a resource app or into the customer's own network, is a third question with its own entries. An application binds the first and usually inherits the second.
SAP Authorization and Trust ManagementSAP Authorization and Trust Management serviceThe OAuth server behind a BTP application: issues the JWT the app checks, holds the scopes and role collections it checks against, and brokers trust to an identity provider. Bound, never installed.sap official, btp is the OAuth 2.0 authorization server: a subaccount cross-configures trust with an identity provider, the provider confirms the user with a SAML bearer assertion, and the service determines that user's authorizations and signs the JWT an application reads; an API client authenticates against the service directly instead, with no user present. The identity provider is Cloud Identity ServicesCloud Identity ServicesIdentity Authentication and Identity Provisioning as one tenant: the login, the user store or the federation to a corporate identity provider, and the provisioning of users into whatever sits behind it.sap official, btp where a tenant has been asked for, and SAP ID service, SAP's own tenant, where nobody has changed the trust. @sap/approuter@sap/approuterSAP's Node.js application router: the single entry point in front of a business application's microservices, which authenticates the user, forwards each request to a backend by route and serves static content.sap official, btp is the standard implementation of the gateway: it starts the authentication, checks for cross-site request forgery and forwards each request to the resource apps with the user information.
Not covered: At the token it signs. The gateway does not hide the backends: its own README states that they stay directly reachable and must validate the JWT and check the scopes themselves, so a request is accepted or refused in the resource app and not on the platform. SAP ID service, the identity provider a subaccount trusts until someone changes that, has no mechanism to enforce multifactor authentication on its users. What a validated caller may then do is authorizationAuthorizationDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.SAP and community, unassessed, a different service and a different question.
core-and-community is a assessment of the corpus: SAP's services and the router behind this door, and independently maintained packages that sit on top of the SAP Authorization and Trust Management service and Identity Authentication. The pages checked state what the platform does and where the application takes over; none states an intent, which is why the relationship is left unassessed rather than called narrow by design.
Independently maintained packages wrap the OAuth server and the identity provider for cases their own documentation does not cover. @arc-mcp/xsuaa-auth@arc-mcp/xsuaa-authThe client-to-server authentication stack for an MCP server on SAP BTP: an XSUAA OAuth proxy, dynamic client registration, a chained bearer verifier, and a separate entrypoint for per-user principal propagation.independent, btp puts the XSUAA OAuth flow, dynamic client registration and bearer verification in front of an MCP server's HTTP route, @saptools/cf-xsuaa@saptools/cf-xsuaaA command line and Node.js API that reads the XSUAA binding of a Cloud Foundry app and prints an OAuth2 client_credentials token for it, cached until it expires.independent, btp prints a deployed Cloud Foundry app's own client_credentials token out of its binding, and sap-mcp-auth@marianfoo/sap-mcp-authA shared browser-login and session module for SAP MCP servers: it drives a Playwright browser through SAP Identity Authentication, caches the session cookies and returns a cookie header an HTTP client can send.independent, btp completes the SAP Identity Authentication login in a browser and keeps the session for a program.
On ABAP the repositories here face outward, the system authenticating itself to someone else's API: a JWT from abap_jwt_generator, Azure through SAP's own OAuth 2.0 client in abapOAuthAzure by Gregor WolfGregor Wolfmaintains 17 entries, wrote 2 posts, contributed to 59 entriesindependent, NTLM in abapNTLM by Lars HvamLars Hvammaintains 13 entries, wrote 1 doc, contributed to 92 entries, and AWS Signature v4 in abap-aws-sigv4. abap-pwnedpasswords is the inbound one, checking a password against the Pwned Passwords breach list.
AS ABAP carries an OAuth 2.0 client, configured in transaction OA2C_CONFIG, that obtains an access token from an external provider such as Google Cloud Platform or Microsoft Azure and renews it with a refresh token. The flows it offers are the authorization code flow and the SAML 2.0 bearer assertion flow.
Not covered: At those two flows in the release checked. A self-signed JWT, an NTLM handshake with a Windows server and an AWS Signature v4 request are not among them, and each is written in ABAP by a repository in this batch.
Checked against the SAP NetWeaver 7.5 documentation; later ABAP Platform releases were not checked for further flows. The community answers the outbound direction, the ABAP system proving who it is to another API, and the inbound side with a logon ticket decoder such as decodesapsso2decodesapsso2A TypeScript library that decodes a MYSAPSSO2 logon ticket into its user, client, system and validity fields, and returns the signature without validating it, so it never shows a ticket is genuine.independent, abap by Marcello UrbaniMarcello Urbanimaintains 14 entries, contributed to 21 entries, which does not validate the ticket. abap_cloud_platformabap_cloud_platformA TypeScript library of the Cloud Foundry calls that walk down to an ABAP service instance, read its SAP_ADT service key and log a user in, so a tool outside the system can reach it.independent, btp obtains a token for an ABAP service instance from outside it, and SAP's Cloud ConnectorCloud ConnectorSAP's on-premises agent that links SAP BTP applications to systems in a customer's own network, as a reverse invoke proxy that exposes only the systems and resources it is configured to allow.sap official, btp forwards the cloud user's identity to an on-premises system.
A UI5 app authenticates nobody itself: the server that delivers it, an application router, a launchpad or the ABAP server, asks for the login. On this door the question is the dev server, which has to put a login in front of the app or carry one to the backend the app calls.
SAP's backend-proxy-middleware, a custom middleware for the UI5 dev server, authenticates the requests it forwards to a backend: it uses credentials maintained with SAP Fiori tools, runs the OAuth routine of the ABAP environment on SAP BTP when scp is set, and supports a reentrance ticket as the authentication type in VS Code.
Not covered: At the backend call. Its options describe how the proxied requests are authenticated; the README describes no login in front of the app the dev server serves.
No community artifact is documented here.
A script, a job or another service calls a protected endpoint of a deployed SAP BTP application and is accepted, with nobody at a browser.
Obtaining the token and keeping it fresh. What the called endpoint then lets the client do is authorization, and carrying a named person's identity is a separate outcome.
Remaining work: Create the service instance and its OAuth client, keep the client secret somewhere the caller can read, call the token endpoint on each run and handle expiry. The endpoint being called still validates the JWT and checks its scopes itself.
cf oauth-token returns.Remaining work: Install it on Node.js 20 or later with the cf CLI on the PATH, and supply SAP_EMAIL and SAP_PASSWORD for the first secret fetch. Nothing about the called endpoint's own validation changes.
Conditions: The one plan in the Discovery Center record is listed in regions marked Neo and in no Cloud Foundry environment. SAP states the service is being removed from the Eligible Cloud Services List on December 31, 2028 in those regions.
Remaining work: Check the entitlement before anything else: the plan has to exist in the region the application runs in, and a subscription has an end date.
People sign in to a BTP application with their corporate account, under the company's own password and multifactor policy rather than SAP's.
The trust and the federation that make the corporate account the one that logs in. Mapping its attributes to what an application expects, and replicating the users themselves, are named here and not assessed.
Remaining work: Ask for a tenant, connect the corporate provider to it, and map the attributes the provider returns to the ones the applications expect.
Remaining work: Cross-configure the endpoints, and move the subaccount off the trust it starts with: that is SAP ID service, where SAP states there is no mechanism to enforce multifactor authentication on its users.
An application on SAP BTP calls a system inside the customer's network and that system sees the person who signed in, not a shared service user.
Carrying the identity to the on-premise system. What that system then permits the person to do is its own, and the cloud login itself is a separate outcome.
Conditions: Trust has to be configured explicitly to the cloud entities whose user tokens are accepted as valid. The calling application's destination configuration decides which of the three authentication types is used.
Remaining work: Install and register the connector, add the access control entry for the system, and set up the certificate and the subject pattern the internal system resolves a logon name from.
Remaining work: Assemble the outgoing request. Its README leaves the headers, the cookies and the forward-proxy call to the consuming server, and the destination and the connector still have to be configured as above.
A person opens a deployed SAP BTP application in a browser, logs in once, and each of the application's own backend endpoints accepts the request as that person.
The login and the token the backends read. Which role collections the person holds is authorization, and reaching a system outside the subaccount is a separate outcome.
Remaining work: The backends. Its own README states that they stay directly reachable past the router and must validate the JWT and check the scopes themselves, so the router alone does not make an endpoint safe to expose.
Remaining work: Cross-configure the trust with the identity provider, declare the application's authorizations in its security descriptor, and bind every app of the application to the one service instance.
Remaining work: Ask for a tenant and establish the trust: a subaccount trusts SAP ID service until someone changes that.
Conditions: The resource app runs on Node.js: the module's README names Node.js applications, and the Java runtime is a separate module that was not read in this pass.
Remaining work: Wire it into each endpoint and write the scope checks; the library validates the token and does not decide what the caller may do.
Neither the package manifest nor the repository tree declares a licence.
No license Neither the package manifest nor the repository tree declares a licence.
Functional boundary The repository publishes no licence, so reusing its code needs the author's permission.
Neither the package manifest nor the repository tree declares a licence.
Before CAP Java 3.0, XSUAA token validation lived in its own cds-feature-xsuaa module, separate from IAS support. The 3.0 release removed cds-feature-xsuaa and unified XSUAA and IAS behind cds-feature-identity, the module that now provides both.
Guidance to add cds-feature-xsuaa as a Maven dependency for authentication in a CAP Java project. It was removed in the 3.0 line, mid-2024 — cds-feature-identity is the replacement for XSUAA as well as IAS.
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
capability:authentication