Starting this week, RIPE NCC members can use OAuth 2.0 to authenticate applications that interact with the RIPE Database. This requested feature supports secure delegated access, allowing third parties to make changes to database objects without exposing user credentials.
Earlier this year, we introduced API keys as an easy-to-use replacement for MD5 hashed passwords, which we plan to deprecate in a few months’ time. Following up on discussions with the community, we worked on an OAuth 2.0 solution that can be used as an alternative to API keys. By enabling both methods, we want to let users choose the best fit for their technical setup. While OAuth 2.0 introduces an additional layer of protection, API keys may still be suitable for simpler use cases or legacy systems.
Why OAuth 2.0?
OAuth 2.0 provides a modern approach using token exchange, which is aligned with current security best practices. It allows members to authorise applications to act on their behalf, without sharing passwords or embedding secrets directly in code. We first introduced our architectural ideas at a RIPE NCC Open House, followed by a presentation at RIPE 90, where we presented our proposed solution, provided demos and worked with volunteers from the community to test our solution.
Based on feedback, our implementation uses the Authorisation Code Flow with PKCE and client secret. This is a secure and recommended setup for confidential clients (i.e. server-side applications capable of securely storing credentials). We also consolidated with the community on the lifecycle of our tokens to balance ease of use with security requirements.
Getting Started
Admin users of provider LIRs can visit the LIR Portal and register their OAuth 2.0 clients. Via a new self-service interface, they can use the credentials provided to build their clients in the Whois or Whois release candidate environments and handle the token exchange. Any SSO users with resources can then visit these client applications and authorise them to handle their RIPE Database resources on their behalf. During this token transaction, no user credentials are exposed. At any point, SSO users can revoke access and end any active sessions through a new page found in their SSO account.
We encourage you to watch our presentation at RIPE 90 to learn more about our technical setup and reach out to us if you have any feedback.
We also want to recommend to members who currently rely on MD5 authentication to begin planning to migrate to either OAuth 2.0 or API keys by the end of 2025.
Comments 0