3. oauth2
OAuth 2.0, qui signifie « Open Authorization » (autorisation ouverte), est une norme conçue pour permettre à un site
Web ou à une application d'accéder aux ressources hébergées par d'autres applications Web au nom d'un utilisateur.
Elle a remplacé OAuth 1.0 en 2012 et constitue désormais la norme industrielle de facto pour l'autorisation en ligne.
OAuth 2.0 fournit un accès consenti et limite les actions que l'application cliente peut réaliser sur les ressources au nom
de l'utilisateur, sans jamais partager les informations d'identification de l'utilisateur.
Bien que le Web soit la principale plateforme d'OAuth 2, la spécification décrit également comment gérer ce type
d'accès délégué à d'autres types de clients (applications basées sur un navigateur, applications Web côté serveur,
applications natives/mobiles, appareils connectés, etc.)
https://datatracker.ietf.org/doc/html/rfc6749
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
https://guide-api-rest.marmicode.fr/securite-des-apis-rest/oauth-2/oauth-2-authorization-code-flow
https://www.ibm.com/docs/en/tfim/6.2.2.6?topic=overview-oauth-20-workflow
4. oauth2
Principes d'OAuth 2.0
OAuth 2.0 est un protocole d'autorisation et NON un protocole d'authentification.
En tant que tel, il est principalement conçu comme un moyen d'accorder l'accès à un ensemble de
ressources, par exemple, des API distantes ou des données utilisateur.
OAuth 2.0 utilise des jetons d'accès.
Un jeton d'accès est un élément de données qui représente l'autorisation d'accéder aux ressources au nom
de l'utilisateur final.
OAuth 2.0 ne définit pas de format spécifique pour les jetons d'accès.
Toutefois, dans certains contextes, le format JSON Web Token (JWT) est souvent utilisé.
Cela permet aux émetteurs de jetons d'inclure des données dans le jeton lui-même.
En outre, pour des motifs de sécurité, les jetons d'accès peuvent avoir une date d'expiration.
5. oauth2
Rôles OAuth2.0
Le concept de rôles fait partie de la spécification de base du cadre d'autorisation OAuth2.0.
Ils définissent les composants essentiels d'un système OAuth 2.0, qui sont les suivants :
● Propriétaire des ressources : l'utilisateur ou le système qui possède les ressources protégées et peut en accorder
l'accès ;
● Client : le client est le système qui a besoin d'accéder aux ressources protégées. Pour accéder aux ressources,
le client doit détenir le jeton d'accès approprié ;
● Serveur d'autorisation : ce serveur reçoit les demandes de jetons d'accès de la part du client et les délivre après
authentification et consentement du propriétaire des ressources. Le serveur d'autorisation expose deux points de
terminaison : le point de terminaison d'autorisation, qui gère l'authentification et le consentement interactifs de
l'utilisateur, et le point de terminaison de jeton, qui fait partie d’une interaction de machine à machine ;
● Serveur de ressources : un serveur qui protège les ressources de l'utilisateur et reçoit les demandes d'accès du
client. Il accepte et valide un jeton d'accès du client et lui renvoie les ressources appropriées.
18. A server side def tokens():
"""
Get the lis of the valid tokens
:param None
:return: a list of the valid token used to access to the
api
"""
try:
return self.__read_parameter('tokens')
except:
return None # no default values
def is_token_valid(givenToken:str=None) -> bool:
"""
Check if the token provided is in the list
:param givenToken: token to check
:return: True is the givenToken is one of the valid one,
else False
"""
for token in self.tokens():
if token == givenToken:
return True
return False
#!/usr/bin/env python3.8
# -*- coding:utf8 -*-
from flask import Flask, request, Response
app = Flask(__name__)
@app.route('/api/my_route, methods=['POST'])
def my_route_fctl():
if request.method == 'POST':
data = request.get_json()
client_ip = request.remote_addr
retdata = []
token =
request.headers['Authorization'].split(" ", 1)[1]
#logger.debug(" - Token='%s'" % (token))
if config.is_token_valid(givenToken=token):
(…)
19. Client using curl
$ curl -X POST http://localhost:3526/api/status
-H "Authorization: Bearer eyJpZCI6NDAsIm5hbWUiOiJzdHJlYW1wcm9iZSJ9.BT6_m8L-
MaeVcmEKnTsu55wFev4"
-d '{ }'
-H 'Content-Type: application/json'
21. 1. need an authenticate server (https://ip/auth or https://ip/oauth2) with a login +
password for the API in order to get :
a. an access TOKEN
b. refresh TOKEN
c. timeout
1. then all http(s) request will be done to the API (https://ip/api) with the access token
and must get a 2XX http return code
1. If a 401 return code is obtain a new request must be to authentication server done
using the refresh token in order to get access token + refresh token and timeout in
order to get a new cycle.
1. To be define :
a. which user can use the auth ?
STREAMPROBE NEEDS
22. database
auth api
check
auth
save
client
HTTP(S) / POST request
login+password
get password from login
rc = 200
access_token
refresh token
timeout in s if granted
if denied
rc = 401
HTTP(S) / POST request
barrer acces_token
save access_token, refresh_token and
timeout
check
tokens
check valid token_access
if granted
rc = 200 + response of the request
rc = 401 (timeout on token_access)
HTTP(S) / POST request
barrer refresh_token
if denied
if denied
if granted
save access_token, refresh_token and timeout
rc = 200, access_token, refresh token, timeout in s
redirect to the api
rc = 401, bad refresh
token
redirect rc = 200, access/refresh token, timeout