OAuth 2.0. Pas de session? (stateless)

Je vais mettre en œuvre OAuth 2.0 et API REST avec elle

à accorder des autorisations différentes pour les utilisateurs et aussi à l'échelle.

À l'échelle ainsi, apatrides est plus facile, car il n'y a

PAS fichier, base de données en mémoire en fonction de la session.

Ci-dessous est la façon dont je comprends OAuth 2.

  1. Serveur OAuth donner un jeton d'accès à un utilisateur.
  2. Le jeton d'accès utilisateur est stocké dans le cookie.
  3. Lorsque l'utilisateur l'accès à l'API REST, l'utilisateur envoie le jeton d'accès.
  4. Serveur reçoit la demande avec jeton d'accès.
  5. Serveur de savoir si le jeton d'accès est valide et que l'utilisateur a la permission de faire la demande.
  6. Faire ou refuser en fonction de l'utilisateur du privilège.

Donc je n'ai pas à vous soucier de stockage de session. Droit?

Jetez un oeil à cette bibliothèque pypi.python.org/pypi/python-oauth2

OriginalL'auteur InspiredJW | 2012-07-12

  1. 9

    Ce que vous décrivez ici, est le OAuth 2 Reconnaissance implicite de l'écoulement. OAuth 2 comprend également trois autres flux, mais comme il semble que votre ressource propriétaire (l'utilisateur) est en train d'initier des demandes à l'aide du navigateur Javascript côté (vous parliez de cookies), c'est le flux, vous devriez aller pour.

    Sur le côté client, OAuth vous demande seulement de stocker les access_token pour accéder à des ressources protégées (et un refresh_token si vous allez pour une expirant access_token).

    Pour vérifier contre jeton d'accès, il devra avoir une base de données côté serveur. 😉
    Bien sûr, sur le côté serveur qu'il doit savoir pour chaque jeton d'accès de l'utilisateur au nom il a été délivré et les étendues qui ont été accordées. En option, il peut également se rappeler et de vérifier les permis redirect_uri pour plus de sécurité. Si c'est ce qu'il voulait dire par "stockage de session", j'ai mal compris la question 😉
    Oubliez la partie concernant la redirect_uri, c'est mal. Je devrais aller au lit 😉

    OriginalL'auteur Jan Gerlinger

  2. 4

    Une innovation plus récente est JWT - JSON Web Jeton.

    Voici un lien pour les specs:
    JWT - JSON Web Jeton

    JWT est une méthode d'utilisation de Haché de jetons à l'aide d'une méthode de Hachage comme HMAC qui représente une base de Hachage Code d'Authentification de Message. Parce que le jeton est haché à l'aide d'une clé secrète, le serveur peut déterminer si le jeton a été falsifié.

    Voici un exemple de méthode pour créer un Hachage de jeton pour JWT:

        public String createTokenForUser(User user) {
        byte[] userBytes = toJSON(user);
        byte[] hash = createHmac(userBytes);
        final StringBuilder sb = new StringBuilder(170);
        sb.append(toBase64(userBytes));
        sb.append(SEPARATOR);
        sb.append(toBase64(hash));
        return sb.toString();
    }

    Voici un exemple de décodage d'un jeton pour s'assurer qu'il n'a pas été altéré:

    public User parseUserFromToken(String token) {
    final String[] parts = token.split(SEPARATOR_SPLITTER);
    if (parts.length == 2 && parts[0].length() > 0 && parts[1].length() > 0) {
        try {
            final byte[] userBytes = fromBase64(parts[0]);
            final byte[] hash = fromBase64(parts[1]);

            boolean validHash = Arrays.equals(createHmac(userBytes), hash);
            if (validHash) {
                final User user = fromJSON(userBytes);
                if (new Date().getTime() < user.getExpires()) {
                    return user;
                }
            }
        } catch (IllegalArgumentException e) {
            //log tampering attempt here
        }
    }
    return null;
}

    Voici un article avec un exemple plus complet: Apatrides Authentification

    OriginalL'auteur anataliocs