OAuth 2.0
OAuth 2.0 is an open standard for authorization that lets an application access a user’s data in another system on their behalf – without sharing the password. Instead of handing over credentials, the user grants a revocable permission, and the application receives a time-limited access token.
OAuth 2.0 is an open authorization standard that allows an application to access a user’s data in another system on that user’s behalf, without the password of that system being disclosed. The user logs in directly with the data-holding service and grants the accessing application an explicitly limited permission that can be revoked at any time. As proof of this permission, the application receives what is known as an access token – a digital key that only allows specific access for a limited time.
The core idea of OAuth 2.0 is the separation of identity and access permission: the accessing app never gets hold of the password; it merely receives a token that precisely defines what it may do. In an ERP context, this is the technical basis that lets an online shop, a marketplace connector or an accounting app safely access the inventory management system, without a plain-text password having to be stored permanently anywhere.
At a glance
- Open standard for authorization – governs access, not sign-in alone
- Apps access data on the user’s behalf without knowing their password
- Core building blocks: access token, refresh token and tightly scoped permissions
- Access is time-limited and can be revoked at any time
- Technical basis for secure API connections from shop, marketplace and accounting to the ERP
How OAuth 2.0 works
OAuth 2.0 describes the interplay of several roles. The resource owner is the user to whom the data belongs. The resource server is the system that holds this data – in an ERP context, for example the inventory management system with its orders and items. The client is the application that wants to access it, for example a shop connector. And the authorization server is the entity that receives the user’s permission and then issues tokens.
The typical flow: the client redirects the user to the authorization server. There the user logs in and confirms which access they want to allow. The authorization server then issues the client an access token. With this token the client calls the protected interface of the resource server, which checks the token and – if valid – releases the requested data. At no point does the client see the user’s password.
Access token, refresh token and scopes
An access token is deliberately short-lived, often valid for only minutes to hours, in order to limit the damage in case of theft. So that the application does not constantly need a new user permission, the authorization server frequently also issues a longer-lived refresh token, which the client uses to request a fresh access token in the background. Scopes, in turn, define the extent of the permission: a scope might allow only reading orders but not creating invoices. This makes it possible to tailor access finely according to the principle of least privilege.
Grant types: the authorization flows
OAuth 2.0 knows several flows – called „grant types“ – depending on who is accessing and how trustworthy the environment is. Choosing the right flow is not a formality but decides the security of the connection.
The authorization code flow is the standard for web and server applications where a human grants the permission; modern implementations additionally secure it with the PKCE method. The client credentials flow works without any user involved and serves pure server-to-server communication – exactly the case when an ERP automatically reconciles stock with a marketplace overnight. Older flows such as the implicit flow or direct password handover (resource owner password credentials) are considered outdated today and are explicitly discouraged by security recommendations.
Why OAuth 2.0 matters
The biggest benefit of OAuth 2.0 is that passwords no longer travel between systems. In the past you often had to give a third-party app your own password so that it could work in another service – a considerable risk, because the app would then have had full and permanent access. With OAuth the app only receives a limited token that allows precisely defined access for a limited time and can be revoked individually at any time, without affecting all the other connections.
For companies this means more control and a smaller attack surface. If a connected application is compromised, the damage is limited to its tightly scoped permissions and the token lifetime. At the same time OAuth 2.0, as a widely used standard, can be used across vendors: nearly every reputable cloud platform, every marketplace and every modern ERP supports it, which greatly simplifies the integration of different systems.
OAuth 2.0 in the ERP system
An ERP rarely stands alone – around the inventory management system cluster the shop system, marketplaces, payment providers, shipping providers and accounting. Each of these connections requires secure, machine access via an API, and OAuth 2.0 is today the preferred authorization mechanism for this. Instead of storing an ERP password in every app, you register the app once with the ERP’s authorization server and let it work via tokens from then on.
In practice the server-to-server case predominates in an ERP context: two systems exchange data in the background without a human clicking a permission for every operation. The client credentials flow is suited to this, where the accessing application authenticates itself with an identifier and a secret. It is important to keep this secret secure, to set scopes as tightly as possible and to renew tokens regularly. Many cloud ERP systems provide a documented REST API including OAuth endpoints for this; with older or on-premise systems, middleware or an API gateway often handles token management.
Distinguishing OAuth 2.0, OpenID Connect and API keys
OAuth 2.0 is often confused with sign-in, but it governs authorization exclusively – that is, the question of what an application may do, not who the user is. For actually establishing identity (authentication), OpenID Connect was developed, which sits as a thin layer on top of OAuth 2.0 and adds what is known as an ID token. Put simply: OpenID Connect answers „Who are you?“, OAuth 2.0 answers „What may you do?“. Together they form the basis of many single sign-on solutions.
OAuth 2.0 differs clearly from a simple API key. An API key is a static, often non-expiring key that does not distinguish between users and grants full permanent access if stolen. OAuth tokens, by contrast, are short-lived, bound to specific scopes and individually revocable. For simple, internal integrations an API key may suffice; but as soon as access happens on behalf of individual users or external applications are involved, OAuth 2.0 is the significantly safer choice.
OAuth 2.0 and the GDPR in the DACH region
Because OAuth 2.0 controls access to personal data – such as customer and order data in the ERP – it directly touches on data protection. The tight definition of scopes feeds directly into the principle of data minimization under the GDPR: an app should only be granted access to the data areas it actually needs. If an external application is connected whose provider processes data outside the EU, the requirements on data processing and third-country transfer must additionally be observed.
For operations it is advisable to log granted permissions and tokens in an audit-proof manner, so that in the event of an audit it is traceable which application accessed which data and when. Likewise there should be a defined procedure to revoke tokens immediately when a service provider leaves or when misuse is suspected. In this way OAuth 2.0 becomes not only a security building block but also a compliance building block of a clean system integration.
Example
Example: marketplace connection of an online retailer
A mid-sized online retailer sells not only through its own shop but also via a large marketplace. A connector is meant to automatically reconcile stock and orders between the marketplace and the ERP. In the past you would have stored the ERP password in the connector for this – with the risk that a compromised connector would have had full access to the entire inventory management system.
With OAuth 2.0 it works differently: the connector is registered once with the ERP and receives a client identifier along with a secret. Via the client credentials flow it fetches a short-lived access token with tightly scoped permissions overnight – only reading stock and creating orders, nothing else. If it turns out that the connector has been compromised, IT revokes its access with a single action, without any passwords having to be changed or other connections touched.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about OAuth 2.0 in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.