Network.OAuth

OAuth tools for using http-client for authenticated requests.

The functions here form the simplest basis for sending OAuthenticated Requests. In order to generate credentials according to the OAuth three-legged workflow use actions in the Network.OAuth.ThreeLegged module.

Authenticating a request

The oauthSimple function can be used to sign a Request as it stands. It should be performed just before the Request is used as it uses the current timestamp and thus may only be valid for a limited amount of time.

oauthSimple creates a new random entropy pool every time it is called, thus it can be both slow and cryptographically dangerous to use it repeatedly as it can drain system entropy. Instead, the plain oauth function should be used which allows for threading of the random source.

oauthSimple :: Cred ty -> Server -> Request -> IO Request

Sign a request with a fresh set of parameters. Creates a fresh SystemRNG using new entropy for each signing and thus is potentially dangerous if used too frequently. In almost all cases, oauth should be used instead.

oauth :: CPRG gen => Cred ty -> Server -> Request -> gen -> IO (Request, gen)

Sign a request with a fresh set of parameters.

Lower-level and pure functionality

When necessary to control or observe the signature more carefully, the lower level API can be used. This requires generating a fresh set of Oa parameters from a relevant or deterministic OaPin and then using sign to sign the Request.

sign :: Oa ty -> Server -> Request -> Request

Sign a request given generated parameters

Generating OAuth parameters

emptyOa :: Cred ty -> Oa ty

Uses emptyPin to create an empty set of params Oa.

freshOa :: CPRG gen => Cred ty -> gen -> IO (Oa ty, gen)

Uses freshPin to create a fresh, default set of params Oa.

emptyPin :: OaPin

An "empty" pin useful for testing. This OaPin is referentially transparent and thus has none of the necessary security features---it should never be used in an actual transaction!

freshPin :: CPRG gen => gen -> IO (OaPin, gen)

Creates a new, unique, unpredictable OaPin. This should be used quickly as dependent on the OAuth server settings it may expire.

OAuth Credentials

data Token ty

Tokens are public, private key pairs and come in many varieties, Client, Temporary, and Permanent.

Constructors

Token !Key !Secret

Instances

Typeable1 Token

Eq (Token ty)

Data ty => Data (Token ty)

Ord (Token ty)

Show (Token ty)

ToJSON (Token ty)

Produces a JSON object using keys named oauth_token and oauth_token_secret.

FromJSON (Token ty)

Parses a JSON object with keys oauth_token and oauth_token_secret, the standard format for OAuth 1.0.

data Cred ty

Credentials pair a Client Token and either a Temporary or Permanent token corresponding to a particular set of user resources on the server.

Instances

Typeable1 Cred

Eq (Cred ty)

Data ty => Data (Cred ty)

Ord (Cred ty)

Show (Cred ty)

data Client

Client Credentials and Tokens are assigned to a particular client by the server and are used for all requests sent by that client. They form the core component of resource specific credentials.

Instances

Data Client

Typeable Client

data Temporary

Temporary Tokens and Credentials are created during authorization protocols and are rarely meant to be kept for more than a few minutes. Typically they are authorized to access only a very select set of server resources. During "three-legged authorization" in OAuth 1.0 they are used to generate the authorization request URI the client sends and, after that, in the Permanent Token request.

Instances

Data Temporary

Typeable Temporary

ResourceToken Temporary

data Permanent

Permanent Tokens and Credentials are the primary means of accessing server resources. They must be maintained by the client for each user who authorizes that client to access resources on their behalf.

Instances

Data Permanent

Typeable Permanent

ResourceToken Permanent

Creating Credentials

clientCred :: Token Client -> Cred Client

temporaryCred :: Token Temporary -> Cred Client -> Cred Temporary

permanentCred :: Token Permanent -> Cred Client -> Cred Permanent

fromUrlEncoded :: ByteString -> Maybe (Bool, Token ty)

Parses a www-form-urlencoded stream to produce a Token if possible. The first result value is whether or not the token data is OAuth 1.0a compatible.

>>> fromUrlEncoded "oauth_token=key&oauth_token_secret=secret"
Just (False, Token "key" "secret")

>>> fromUrlEncoded "oauth_token=key&oauth_token_secret=secret&oauth_callback_confirmed=true"
Just (True, Token "key" "secret")

OAuth Configuration

data Server

The Server information contains details which parameterize how a particular server wants to interpret OAuth requests.

Constructors

Server

Fields

parameterMethod :: ParameterMethod

signatureMethod :: SignatureMethod

oAuthVersion :: Version

Instances

Eq Server

Data Server

Ord Server

Show Server

Typeable Server

defaultServer :: Server

The default Server parameterization uses OAuth recommended parameters.

data ParameterMethod

The OAuth spec suggest that the OAuth parameter be passed via the Authorization header, but allows for other methods of transmission (see section 3.5. Parameter Transmission) so we select the 'Server'\'s preferred method with this type.

Constructors

AuthorizationHeader

Place the Oa parameters in the Authorization HTTP header.

RequestEntityBody

Augment the www-form-urlencoded request body with Oa parameters.

QueryString

Augment the www-form-urlencoded query string with Oa parameters.

Instances

Eq ParameterMethod

Data ParameterMethod

Ord ParameterMethod

Show ParameterMethod

Typeable ParameterMethod

data SignatureMethod

OAuth culminates in the creation of the oauth_signature which signs and authenticates the request using the secret components of a particular OAuth Cred.

Several methods exist for generating these signatures, the most popular being HmacSha1.

Constructors

HmacSha1

Plaintext

Instances

Eq SignatureMethod

Data SignatureMethod

Ord SignatureMethod

Show SignatureMethod

Typeable SignatureMethod

QueryValueLike SignatureMethod

data Version

OAuth has progressed through several versions since its inception. In particular, there are two community editions "OAuth Core 1.0" (2007) and "OAuth Core 1.0a" (2009) along with the IETF Official version RFC 5849 (2010) which is confusingly named OAuth 1.0.

/Servers which only implement the obsoleted community edition "OAuth Core 1.0" are susceptible to a session fixation attack./

If at all possible, choose the RFC 5849 version (the OAuth1 value) as it is the modern standard. Some servers may only be compliant with an earlier OAuth version---this should be tested against each server, in particular the protocols defined in Network.OAuth.ThreeLegged.

Constructors

OAuthCommunity1

OAuth Core 1.0 Community Edition

OAuthCommunity1a

OAuth Core 1.0 Community Edition, Revision A

OAuth1

RFC 5849

Instances

Eq Version

Data Version

Ord Version

Show Version

Typeable Version

QueryValueLike Version

All three OAuth 1.0 versions confusingly report the same version number.