oauth2 openid connect application de bureau javascript (électron)

Question

Quel est le flux oauth2 correct pour une application de bureau? En plus d'une application de bureau, j'ai une interface graphique Web SPA qui utilise le flux implicite. Là, cela n'a pas d'importance si le client redirige après 3600 vers le fournisseur d'identité pour émettre un nouveau jeton d'accès. Mais l'application de bureau doit fonctionner 24 heures sur 24, 7 jours sur 7 ou 24 heures sur 24, 7 jours sur 7. Il doit donc actualiser automatiquement le jeton d'accès via un refresh_token. Mais puisque le flux implicite ne fournit pas de jetons d'actualisation, il s'agit probablement du mauvais flux pour une application de bureau, n'est-ce pas?

Je suppose que j'ai besoin du flux de code d'autorisation, qui fournit un refresh_token. Mais les demandes d'authentification nécessitent un redirect_uri. Disons que je veux utiliser Google comme fournisseur OpenID. Avec google, il semble que je ne puisse pas enregistrer les informations d'identification du client avec un schéma d'URI personnalisé (https://developers.google.com/identity/protocols/OpenIDConnect). Qu'est-ce que le travail est d'enregistrer par exemple http://localhost:9300, qui pourrait théoriquement être géré par l'application.

A

Quel est le flux oauth2 correct pour une application de bureau pour recevoir un refresh_token?

B

Puis-je attraper le redirect_uri via un schéma d'URI personnalisé sans utiliser le flux implicite (Google IdP)? Il est beaucoup plus facile d'écouter un schéma uri personnalisé que d'écouter sur un port tcp local.

C

Ceci est plus une question générale. Habituellement, les applications de bureau sont des applications publiques, donc je ne devrais pas inclure client_secret non? Ainsi, le seul flux qui resterait est le flux implicite. Mais comment puis-je renouveler les jetons d'accès selon les spécifications sans déranger l'utilisateur de bureau tous les 3600s? Dans mon cas, je pourrais publier l'application localement, donc pas publique, mais comment est-ce pour une application publique?

Answer 1

A - code d'autorisation Grant

B - Je ne sais pas ici, vous pouvez register a Custom URI Scheme

C - Pas assez d'informations fournies. Utilisez-vous les bibliothèques AppAuth? Si c'est le cas, vous devez utiliser PKCE et des mesures de sécurité supplémentaires pour le jeton d'actualisation ne doivent pas être nécessaires, en supposant que le client n'envoie jamais le jeton d'actualisation à personne d'autre que l'IDP via une connexion sécurisée.

Est-ce que cela aide?

Answer 2

A: Oui utiliser la subvention de code

B: oui utiliser un modèle personnalisé. Dans votre cas, vous devez utiliser l'inverse de votre ID client. par exemple. com.googleusercontent.apps.123 est la notation DNS inverse de l'ID client. Enregistrez votre client en tant que "Autre" dans la console développeur de Google.

C: Oui, le secret client ne doit pas être inclus. C'est pourquoi vous n'avez pas besoin d'envoyer le secret pour les clients natifs ("Autre") lors de l'échange du code pour un jeton d'actualisation. Laissez ce champ vide et ça marchera.

Comme suggéré par jwilleke, veuillez utiliser une bibliothèque AppAuth si elle est disponible pour votre cas d'utilisation car elle gérera également certains des problèmes de sécurité (PKCE).

Answer 3

Pour les applications natives (de bureau), vous pouvez suivre OAuth 2.0 for Native Apps. Mais ceci est encore en cours de révision et vous pouvez vous référer à la dernière version du lien fourni.

Avec ce flux, vous pouvez utiliser le flux de code d'autorisation pour obtenir à la fois le jeton d'accès et un jeton d'actualisation. Les jetons d'actualisation devraient résoudre le problème lié à l'UX en ce qui concerne l'utilisation étendue de l'application (24h/24 et 7j/7). Selon ce document de travail, il existe des directives strictes sur l'authentification des clients. Section 8.5 discuter à leur sujet. Comme il est dit des informations d'identification des clients ne sont pas recommandés

Pour cette raison, et ceux mentionnés au paragraphe 5.3.1 de [RFC6819], il ne RECOMMANDÉ pour les serveurs d'autorisation d'exiger client authentification des applications natives publiques clients utilisant un secret partagé

De même que nvnagr a mentionné dans sa réponse, PKCE [RFC7636] est un must pour les clients publics natifs.