a POSIX-C implementation of the http://oauth.net/ protocol. libOauth provides functionality to encode URLs and sign HTTP request data according to the oAuth standard.

OAuthリクエストはOpenSocialガジェットから外部サーバーにリクエストを行う際に利用できる認証方式のひとつです。OAuthは別名3-legged OAuth、OAuth Coreと呼ばれます。ガジェットからOAuthリクエストを行うことで、ディベロッパーはユーザーに直接認証をさせ、セキュアにプライベートデータをマッシュアップすることができるようになります。 OAuth自体複雑な仕組みですが、OpenSocialでは、ガジェットディベロッパーが簡単に実装できるようにデザインされいます。ここではOAuthの仕様は割愛し、gooホームからOAuthリクエストを行う際の手順についてのみ言及します。 なお、独自にOAuthのサービスプロバイダを実装することは可能ですが、本ドキュメントでは実装済みサービスを利用する方法についてのみ言及し、サービスプロバイダの実装方法については触れませんのでご

Extension: Problem Reporting This is an extension to OAuth, defining how a Service Provider can report a problem to a Consumer. This enables the Consumer to provide a more satisfying experience to the User, by solving the problem quietly or giving the User actionable advice for solving the problem. To discuss this extension, please use the API failure handling thread in the Google Group OAuth Exte

Abstract This draft describes a mechanism to combine an OpenID authentication request with the approval of an OAuth request token. Table of Contents 1.  Requirements notation 2.  Terminology 3.  Purpose of this Specification 4.  Overview 5.  Extension Namespace 6.  Discovery 7.  Before Requesting Authentication - Registration 8.  Requesting Authentication 9.  Authorizing the OAuth Request

Abstract This specification defines the concept of an Authorization Session which represents the authorization granted to the Consumer to access Protected Resources on behalf of the User. OAuth Core 1.0 assumes that the Authorization Session lifetime and the Access Token lifetime are equal. This specification defines a mechanism for Service Providers to issue Access Tokens with shorter life

2.  Notation and Conventions The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level D

Abstract OAuth Core 1.0 defines a protocol for delegating user access to Consumer applications without sharing the user's private credentials. Some consumer applications use the RSA_SHA1 signature method. To verify RSA_SHA1 signatures, Service Providers need to be in possession of an authentic copy of the consumer application's public key. Whenever a consumer application changes the private key it

Abstract This memo describes a method for using the OAuth flow to sign a request made between a Consumer and Service Provider without User involvement, which is either absent or handled by other means. It enables OAuth to be used as a replacement to HTTP Basic authentication and extends the capabilities of the OAuth Consumer credentials. OAuth Core 1.0 defines a protocol for delegating user access

Abstract This specification extends the OAuth signature to include integrity checks on HTTP request bodies with content types other than application/x-www-form-urlencoded. Table of Contents 1.  Introduction 2.  Notation and Conventions 3.  The oauth_body_hash Parameter 3.1.  Hash Algorithm 3.2.  Hash Calculation 4.  Changes to OAuth Request Signing 4.1.  Sending Requests 4.1.1.  When to Inc

 This specification was obsoleted by OAuth Core 1.0 Revision A on June 24th, 2009 to address a session fixation attack. The OAuth Core 1.0 Revision A specification is being obsoleted by the proposed IETF draft draft-hammer-oauth. The draft is currently pending IESG approval before publication as an RFC. Implementers should use RFC 6749: The OAuth 2.0 Authorization Framework instead of this specif