I am implementing an OAuth Provider using DevDefined library. I wonder if there is any recommended database structure for storing consumer and token data on the server side. Any advice on this would be appreciated!
相关问题
- Script fails on SpreadsheetApp.openById - Requires
- Is service account in google calendar api v3 the r
- How to better organise database to account for cha
- Database best practices - Status
- “Unauthorized” when invoking an API App from Azure
相关文章
- Proper WWW-Authenticate header for OAuth provider
- Storing User Settings - anything wrong with using
- Get expire time of OAuth session
- Are PostgreSQL VIEWS created newly each time they
- What is the difference between UNIQUE, UNIQUE KEY
- Use cases of OAuth2.0
- Optional Database Entities
- WooCommerce API OAuth in python
NB: The answer below is applicable mostly to OAuth 1.0
I don't really know anything about the DevDefined library. But here is a non-technical description of the database design I ended up working with in my latest project, using an SQL database.
It should cover everything needed to follow the basic specification. I've tried to keep it down to an absolute minimum.
RequestTokens
AccessTokens
Consumers (registered third party applications)
UsedNonces
The handling of nonces was really the biggest design question for me. OAuth tells you to never allow the same nonce to be used with the same timestamp ever again. But that would make for an infinitely huge database. I think most providers batch away old nonces at least once in a while.
I routinely clear away nonces older than 5 minutes, based on the premise that all requests with a timestamp older than 5 minutes are rejected. I am slightly forgiving when checking timestamps, they need to be UTC and either not older than 5 minutes, and not ahead of my server time more than one minute.
There are a few ways to approach this, one example of an application implementing both provider and consumer functionality is Atlassian's Jira - here is their structure:
Normally the basics mimic the specification - except for custom extensions you may introduce to deal with: