Shutterfly Open API  |  Authentication and Authorization


To access a Shutterfly user's private resources, your app will need authentication of itself and/or the user; and authorization (or permission) to those resources.

  • Authentication: The Shutterfly Open API provides a choice of paths, User Authentication or App Authentication Your app would use one or the other.
  • Authorization: For the present, User Authentication confers an implicit permission to all of the user's resources, and App Authentication confers the same permission if the user grants it. Nothing more is needed. Shutterfly may introduce a more fine-grained, explicit system of permissions in the future.

User Authentication

This path is for downloaded applications, or any app that cannot fully guard (hide) its shared secret. Example: a computer desktop application, or a downloadable browser widget that talks directly with Shutterfly. The user inevitably downloads the secret at some point, and hence, it is not really a secret.

With User Authentication, your app sends the user to a special Shutterfly page where she signs in - or, if she does not yet have a Shutterfly account, she may sign up as a new Shutterfly user. Either way, Shutterfly calls back to your app, passing a token that will let your app make its Shutterfly Open API calls. This process is also called Interactive Sign-in. Your app never sees the user's Shutterfly password. Your app is given an "auth token", which it passes on successive calls to the Shutterfly Open API.

The auth token generally expires after two days. Your app should protect it by using SSL (https) on every Shutterfly Open API call where the token is present. When your app needs a new token, it calls to Interactive Sign-in again, and the user must sign in to Shutterfly again.

Your app passes the auth token on Shutterfly Open API calls as a special HTTP header, like this:

X-OPENFLY-Authorization: SFLY user-auth={the auth token}

for example,

X-OPENFLY-Authorization: SFLY user-auth=000020654581|1207184770811|610685903d963e98a5aa5766e57fb70340302493

If it is more convenient, your app can set a classic HTTP Authorization header, like this:

Authorization: SFLY user-auth=000020654581|1207184770811|610685903d963e98a5aa5766e57fb70340302493

Please note:

  • Shutterfly recommends using X-OPENFLY-Authorization. Your HTTP library may have problems using the Authorization header; it may silently discard your header in favor its own information (even if it has none), which can lead to confusing results.
  • The Image Upload API takes the auth token as a multipart/form-data parameter, not as a header. See its documentation for more details.
  • There is another way to obtain the same kind of auth token: there is a direct User Authentication API. But it requires your app to collect the user's Shutterfly password. Shutterfly generally prefers that you use Interactive Sign-in and never collect the user's Shutterfly password.

App Authentication

This path is for non-downloaded applications, or any app that truly guards its shared secret. Example: a Web site whose servers make back-end calls to the Shutterfly Open API. The app would keep its shared secret strictly on the server side, behind a firewall, etc.

With App Authentication, your app sends the user, one time, to a Shutterfly page where she signs in and can then grant permission to your app. If the user grants permission, Shutterfly calls back to your app, passing a token that will let your app make future Shutterfly Open API calls without the user having to sign in to Shutterfly. This process is also called Seamless Sign-in. As with Interactive Sign-in, your app never sees the user's Shutterfly password. Your app is given a "permanent user token", which it passes on its calls to the Shutterfly Open API.

The user token is permanent. Your app need not protect it with SSL (https) on Shutterfly Open API calls; http may be OK, depending on the specific API. If your app loses the token, send the user through the App Authentication process again - i.e., your app can easily re-obtain the token, at the cost of the user being present to sign in again.

Your app passes the user token on Shutterfly Open API calls as a URL parameter, like this:

oflyUserid={user token}

for example,

oflyUserid=9BcNWjVs1g

Call Signature and "Guarded Secret"

Note that Call Signature plays a role in both systems. With User Authentication, it at least tells Shutterfly that the URL parameters (such as timestamp) are part of an integral call. With App Authentication, it does more: it authenticates your app to Shutterfly.

The difference arises from the concept of "guarding" the shared secret. Guarding the secret - that is, keeping it hidden and unknown to third parties - is the responsibility of the application developer, host and owners. Via app configuration, Shutterfly lets them declare their intent to guard the shared secret. An app that declares its secret as guarded has accepted responsibility for protecting it, and is then eligible for App Authentication. Other apps must use User Authentication.

previous
Call
Signature
next
Atom Concepts
© 1999-2014 Shutterfly, Inc. All rights reserved.