 |
| Original OAuth Logo by Chris Messina |
When you use the CloudBees console, GrandCentral, it is interacting with the CloudBees API under the covers. You might also use the the CloudBees SDK at the command line, and the SDK interacts with the same CloudBees API to perform operations like application and database creation, binding of apps to databases and so on. Today we're very happy to announce that we are supporting OAuth-based authorization capabilities to the CloudBees API. Once a CloudBees user grants permission to a third-party application via OAuth, that application can extend the functionality of the CloudBees platform using the CloudBees API, on behalf of the CloudBees user. This is the same kind of authorization mechanism used by Facebook and Google to gate access to their underlying platform capabilities. Providing protected access to CloudBees user resources in an industry-standard way that is both secure and extensible is important for developers and partners to be able to weave together new capabilities on the platform.
We have quite extensive developer documentation online, as well as an example client app . But, if you're not familiar with OAuth, let's take a very quick tour here. The specifics of participants in an authorization flow and their roles are captured in a scenario. For example, in a browser-based app, there will actually be an end-user, whereas in server-based apps, there is often no user available to interact with directly. CloudBees OAuth2 supports various scenarios for different client types - Web Application, Installed Application, User Agent Apps (JavaScript in a Web Browser) and Server Application.
Before anything can happen, the app that wants to access a protected resource has to be registered with the owner of that resource – in this case, CloudBees. That registration is done using the Application Registration API via HTTPS-based communication with CloudBees-hosted endpoints. In fact, all interactions with CloudBees OAuth must be done using HTTPS.
Now envision that the end-user wants to use the app and is operating within a browser. The pre-registered web app needs to request authorization from the CloudBees OAuth server. The OAuth server prompts the end-user with information about what the app wants access to and requests approval. If the user agrees, the OAuth Server provides a Token to the app. The app can use the Token to make a request to the protected resource – the CloudBees API – on behalf of the user.
What are the benefits of this formalized dance? Prior to our using OAuth, apps would have to use the user's api_key and secret to interact with the CloudBees API. With OAuth, there is a lot of flexibility built-in, and it allows secrets to be shared in a tightly controlled manner only between the server hosting the protected resource and the OAuth server that the user and the app interact with. Grants can be revoked on a fine-grain basis as a result. Also, because every app wanting access to protected resources must register with the owner, CloudBees controls what applications are even allowed to interact with CloudBees, while you control the access to your resources on CloudBees.
Please fork the OAuth client app example and take it for a spin! Stay tuned for finer-grained access to an expanded set of services as we bring even more parts of the CloudBees Platform further into the open for your coding pleasure.
Thanks go to Vivek Pandey for making OAuth a great new addition to the CloudBees Platform!
-- Steven G. Harris
Senior VP of Products
CloudBees, Inc.
cloudbees.com
Steven G. Harris is Senior Vice President of Products at CloudBees. Prior to joining CloudBees, Steve led the Java server business and Java EE JCP involvement at Oracle for over 10 years.