Unless you allow anonymous access to your collection, you'll need to have some kind of software that guards access to your books, and possibly even to the OPDS feeds themselves. There are a variety of ways of doing this, but most of the time this means implementing HTTP Basic Auth and looking up credentials in some kind of data store.
Token service
The token service is only necessary in one case:
- You are a distributor who sells access to your collection to libraries.
- But you don't want the libraries downloading your books, rehosting them, and serving them to their patrons.
- Instead, you want the library patrons to come to you whenever they want to download a book.
To see the problem here, consider a specific case. I come to your site and say "I'm a patron of library X; give me this book." You've agreed to hand out copies of this book to patrons of library X, but how do you know I'm really a patron of library X? Am I supposed to show you my library card? How do you know it's legitimate?
When you set up the contract with library X, you sent out a username and password for that library to use when accessing your OPDS server. If I, the patron, had that username and password, I could access your OPDS server and download the book. But I shouldn't be given that username and password. I'm not library X, I'm just a patron of library X.
Library X shouldn't have to give out its credentials to every patron who asks. It should be able to delegate its authority to a patron for purposes of downloading a specific book from your server. This is what bearer token propagation is for, and it's covered in a separate document.
Authentication For OPDS
An Authentication For OPDS document explains what it takes for a person to actually get access to your collection. You can advertise three authentication techniques in your Authentication for OPDS document:
- Anonymous access (no authentication)
- HTTP Basic Auth (username/password)
- OAuth client credentials grant (used only by the token service below)
We also support a wrapper around OAuth's authorization code grant. For a working example, see Clever login in the Open Ebooks app. However, the situation there is so unusual that we don't want to give general advice. If you authenticate your users with an OAuth authorization code grant, contact us and we'll figure out how to work you into this strategy.
Collection metadata extensions (e.g. Library Registry) The library registry and the SimplyE mobile client also recognize a large number of extensions to Authentication For OPDS which let you specify detailed information about your collection: things like a description, the audiences and geographic locations you serve, the estimated number of titles you have in various languages, and even the color scheme to use when displaying your collection.
The automatic library registration process (not yet designed) takes your Authentication For OPDS document as its input. These extensions contain the information it needs–description, geographic locations, and so on–to put your OPDS server in the library registry and help people find it.
Anonymous access
Even if your OPDS server allows anonymous access, you can't join the SimplyE library registry without an Authentication For OPDS document. There are two reasons for this. First, you need to explicitly state that your OPDS server allows anonymous access, and the Authentication For OPDS document is the place to do that. Second, the library registry needs all that extension information–your colleciton's description, audiences and languages, and so on–and that stuff goes in the Authentication for OPDS document.
Static generation In most cases the Authentication For OPDS document can be a static document. You only need to regenerate it if something about your server's code or configuration changes.
