6
votes

Une bonne approche pour un schéma de jeton d'API Web?

Je travaille sur une API de repos pour une application Web qui, jusqu'à présent, nous nous sommes développés en interne pour quelques applications de compagnon. Maintenant que nous examinons l'ouverture des développeurs extérieurs, nous souhaitons ajouter des jetons à l'API afin d'aider à identifier qui apporte des demandes et en général d'aider à gérer son utilisation. À ce stade, nous utilisons HTTPS et authentification de base pour l'authentification de l'utilisateur sur l'API.

Le schéma de jeton que nous avons discuté serait très simple dans lequel chaque développeur serait attribué à 1 ou plus de jetons et que ces jetons seraient transmis comme un paramètre avec chaque demande.

Ma question est si vous avez fait quelque chose de similaire auparavant, comment l'avez-vous fait (avez-vous fait plus ou moins, comment avez-vous géré la sécurité, etc.) et avez-vous des recommandations?


1 commentaires

Pour quiconque intéressé, j'ai écrit une histoire sur la façon de passer de l'absence de sécurité à une API de repos sécurisée sans Oauth ici: thebuzzmedia.com/... Le problème n'est pas avec l'identification (jetons uniques, etc.) Le problème est de la fermeture des vecteurs d'attaque et des personnes qui utilisent vos utilisateurs . Sur HTTP nécessitant une somme de contrôle ou un "HMAC" - Signature de toutes les valeurs de la demande avec une clé secrète que le client et le serveur savent. Sur HTTPS, il est beaucoup plus facile, un jeton simple fonctionne bien.


3 Réponses :


6
votes

Tout d'abord, vous voudrez peut-être regarder http://oauth.net . En fonction de vos usecases, cela pourrait fournir la sécurité dont vous avez besoin.

Quant au jeton, c'est une blob de la plupart des protocoles, y compris OAuth. Vous pouvez mettre toutes les informations dont vous avez besoin dans n'importe quel format.

Voici ce que nous faisons,

  1. Nous assignons d'abord chaque développeur une clé avec un secret associé.
  2. Le jeton lui-même est une paire de nom de nom cryptée. Nous mettons des choses comme le nom d'utilisateur, l'expiration, l'identifiant de la session, les rôles, etc. Il est crypté avec notre propre secret pour que personne d'autre ne puisse le faire.
  3. Pour une utilisation facile avec Web API, nous utilisons la version URL-Safe de base64 de sorte que le jeton est toujours URL-Safe.

    espère que cela aide!


0 commentaires

2
votes

Vous voudrez peut-être aussi penser à ajouter un joken sur le temps qui vous permettrait de limiter la quantité de temps qu'une demande est valide. Cela vous aidera à essayer de faire une attaque de replay.

Vous auriez un appel de poignée de main pour obtenir / attribuer un jeton valide de temps basé sur le développeur de développement ci-dessus. Ce jeton serait stocké localement et transmis à l'appelant.

Le développeur utiliserait alors cette clé dans une demande de validation de la demande et du développeur.

Par exemple, la clé peut ensuite être utilisée pendant 5 minutes ou pour 10 demandes ou tout ce que vous définissez. Après cela, le jeton basé sur le temps généré est supprimé de la liste valide et ne peut plus être utilisé. Le développeur devra ensuite demander un nouveau jeton.


0 commentaires

1
votes

UUID est très bon pour toute clé aléatoire temporaire que vous avez envie de détériorer. Imprévisible et rapide à générer, avec des collisions si peu probables qu'ils soient effectivement uniques. Faire de belles clés de session aussi.


0 commentaires