The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from Web services (Service Providers) via an API, without requiring Users to disclose their Service Provider credentials to those Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API-oriented authentication.
For Consumer developers, OAuth is a method to publish and interact with protected data.
For Service Provider developers, OAuth gives users access to their data while protecting their account credentials.
One use case would be allowing a printing service, printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider), without requiring Users to reveal their photos.example.net credentials to printer.example.com.
OAuth allows the user to selectively grant access to their private resources housed on one site (called the Service Provider), to another site (called the Consumer). In other words, OAuth enables you to grant access to some of your information without sharing all of your identity.
OAuth does not require a specific user interface or interaction pattern, nor does it specify how Service Providers authenticate Users, making the protocol ideally suited for cases where authentication credentials are unavailable to the Consumer, such as with OpenID.
OAuth aims to unify the experience and implementation of delegated web service authentication with a single, community-driven protocol. OAuth builds on existing protocols and best practices that have been independently implemented by various websites. An open standard, supported by large and small providers alike, promotes a consistent and trusted experience for both application developers and the users of those applications.
What is publicly known as "OAuth" is really the "OAuth Core 1.0" specification. The "Core" designation is used to stress that this is the skeleton upon which other extensions and protocols may be built. OAuth Core 1.0 does NOT by itself provide many desired features such as automated discovery of endpoints, language support, support for XML-RPC and SOAP, standard definition of resource access, OpenID integration, a full range of signing algorithms, or any number of other great ideas posted to the OAuth group.
This was intentional and is viewed by the authors as a benefit. As the name implies, Core deals only with the most fundamental aspects of the protocol:
- Establish a mechanism for exchanging a username and password for a token with defined rights
- Provide tools to protect these tokens
More details can be found here.
Credentials bearing tokens enable a user to provide their credentials in tokenized form in cases where HTTP redirection to a browser plus human interaction is unavailable or unsuitable. For example, intermediary intelligent agents, mobile phones, or set-top devices.
- Explaining OAuth
- Visual OAuth Usage Example
- OAuth Beginners Guide - Part 3
- OAuth specification
- Getting Started with OAuth
- OAuth Access Tokens Using Credentials specification
- OAuth: HTTP Authorization Delegation Protocol specification
- Google OAuth Group
- OAuth & OpenID Combined - Protocol Extension
Virtuoso- and OpenLink-specific OAuth Information
- Virtuoso OAuth server
- Virtuoso Authentication Server UI.
- Using OAuth with ODS
- ODS Ubiquity Commands
- Virtuoso OAuth Implementation
- ODS Controllers
- Testing Virtuoso OAuth with 3rd Party OAuth Clients
- OAuth Ubiquity Tutorial
- Virtuoso OAuth Test Tool for ODS Controllers
- Virtuoso SPARQL OAuth Tutorial
- ODS Ubiquity Tutorials
- OAuth Applications Authentication examples
- OAuth API