Ils ne sont pas très gros (peut-être 15 ou 20 caractères, je ne me souviens plus exactement), et sont des chaînes. Note: ceci pourrait changer. Rien dans la spécification OAuth ne décrit comment générer des jetons et des secrets, ni à quoi ils ressemblent. Je m'attends à ce qu'ils soient toujours des ficelles, mais je pourrais vouloir rendre la colonne un peu plus grande que ce qui est actuellement nécessaire pour la contingence. Si vous les stockez dans la base de données, vous avez besoin d'un autre moyen d'authentifier les utilisateurs afin que vous sachiez quels sont les jetons à retirer et à utiliser pour qu'ils ne puissent pas être utilisés avec malveillance. Si vous avez déjà cela et que cela fonctionne, alors c'est logique, sinon vous voudrez peut-être le repenser.
Une autre façon de le faire est de stocker leurs jetons dans un cookie, les inconvénients sont que (si vous ne cryptez pas ou n'utilisez pas SSL) ils voyagent sur le net en clair, et s'ils changent ordinateurs, navigateurs, ou supprimer leurs cookies, vous devez les faire passer à travers l'ensemble du processus OAuth à nouveau.
Pour un site Web sans autre autorisation, je les crypterais et les stockerais dans un cookie. Si vous les avez déjà connectés, associez à la fois le jeton et le secret avec le login et stockez-les dans la base de données.
Il existe également d'autres moyens. Vous pouvez utiliser un ID généré de manière aléatoire comme un GUID/UUID dans un cookie pour pointer vers un enregistrement dans une base de données avec les jetons si vous ne souhaitez pas utiliser le chiffrement. Dans l'ensemble, cela dépend de la façon dont vous voulez que votre application se comporte du point de vue des utilisateurs.
Assurez-vous de gérer le cas où l'utilisateur désautorise également votre application.