SlideShare une entreprise Scribd logo
1  sur  28
Secure a REST API
Thierry GAYET - 01/2024
oauth2
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
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.
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.
oauth2
oauth2
oauth2
oauth2
source : https://www.youtube.com/watch?v=QrGu7ITlSog&ab_channel=BreizhCamp
Testtree feedback/needs
(vmaf)
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):
(…)
Client using curl
$ curl -X POST http://localhost:3526/api/status 
-H "Authorization: Bearer eyJpZCI6NDAsIm5hbWUiOiJzdHJlYW1wcm9iZSJ9.BT6_m8L-
MaeVcmEKnTsu55wFev4" 
-d '{ }' 
-H 'Content-Type: application/json'
TOKEN GENERATION
$ nano genToken.py
#!/usr/bin/env python3
# -*- coding:utf8 -*-
from itsdangerous import URLSafeSerializer
auth_s = URLSafeSerializer("secret key", "auth")
id:int = input(" - Select a number : ")
name:str = input(" - Select a product name : ")
token = auth_s.dumps({"id": id, "name": name})
print(token)
# Examples :
# eyJpZCI6NSwibmFtZSI6Iml0c2Rhbmdlcm91cyJ9.6YP6T0BaO67XP--9UzTrmurXSmg
# eyJpZCI6NDAsIm5hbWUiOiJzdHJlYW1wcm9iZSJ9.BT6_m8L-MaeVcmEKnTsu55wFev4
# eyJpZCI6IjI1IiwibmFtZSI6InN0cmVhbXByb2JlIn0.uzPor5MlOWYQJ0PDgVbqtkHNfiw
data = auth_s.loads(token)
print(data["name"])
print(str(data["id"]))
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
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
Benoit feedback/needs
Benoit feedback/needs
Cybersec.
https://owasp.org/www-project-api-security/
https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_(en).pdf.pdf
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
https://developers.google.com/identity/protocols/oauth2/resources/best-practices?hl=fr

Contenu connexe

Similaire à Secure a REST API for external public access

(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)Microsoft Décideurs IT
 
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)Microsoft Technet France
 
Oauth2 et OpenID Connect
Oauth2 et OpenID ConnectOauth2 et OpenID Connect
Oauth2 et OpenID ConnectPascal Flamand
 
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...Philippe Beraud
 
ASFWS 2011 : CAS, OpenID, SAML concepts, différences et exemples
ASFWS 2011 : CAS, OpenID, SAML  concepts, différences et exemplesASFWS 2011 : CAS, OpenID, SAML  concepts, différences et exemples
ASFWS 2011 : CAS, OpenID, SAML concepts, différences et exemplesCyber Security Alliance
 
Le futur de l'authentification webAuthn
Le futur de l'authentification webAuthnLe futur de l'authentification webAuthn
Le futur de l'authentification webAuthnChristophe Villeneuve
 
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemples
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemplesCAS, OpenID, Shibboleth, SAML : concepts, différences et exemples
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemplesClément OUDOT
 
LemonLDAP::NG et le support SAML2 (RMLL 2010)
LemonLDAP::NG et le support SAML2 (RMLL 2010)LemonLDAP::NG et le support SAML2 (RMLL 2010)
LemonLDAP::NG et le support SAML2 (RMLL 2010)Clément OUDOT
 
LemonLDAP::NG et le support SAML2
LemonLDAP::NG et le support SAML2LemonLDAP::NG et le support SAML2
LemonLDAP::NG et le support SAML2Clément OUDOT
 
Sayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexes
Sayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexesSayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexes
Sayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexesSayehHiba1
 
CAS, OpenID, SAML : concepts, différences et exemples
CAS, OpenID, SAML : concepts, différences et exemplesCAS, OpenID, SAML : concepts, différences et exemples
CAS, OpenID, SAML : concepts, différences et exemplesClément OUDOT
 
Authentification sociale en angular 1.pptx
Authentification sociale en angular 1.pptxAuthentification sociale en angular 1.pptx
Authentification sociale en angular 1.pptxMickael ROLO
 
[JDLL 2016] OpenID Connect et FranceConnect
[JDLL 2016] OpenID Connect et FranceConnect[JDLL 2016] OpenID Connect et FranceConnect
[JDLL 2016] OpenID Connect et FranceConnectClément OUDOT
 
OIDC jusque dans les applications mobiles
OIDC jusque dans les applications mobilesOIDC jusque dans les applications mobiles
OIDC jusque dans les applications mobilesxavierguimard
 
SOLID : les principes à l’origine du succès de Symfony et de vos applications
SOLID : les principes à l’origine du succès de Symfony et de vos applicationsSOLID : les principes à l’origine du succès de Symfony et de vos applications
SOLID : les principes à l’origine du succès de Symfony et de vos applicationsVladyslav Riabchenko
 
Gérer facilement les identités dans le cloud
Gérer facilement les identités dans le cloudGérer facilement les identités dans le cloud
Gérer facilement les identités dans le cloudAymeric Weinbach
 

Similaire à Secure a REST API for external public access (20)

(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
 
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
 
Oauth2 et OpenID Connect
Oauth2 et OpenID ConnectOauth2 et OpenID Connect
Oauth2 et OpenID Connect
 
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...
Vous avez dit protocoles Web d'authentification et d'autorisation ! De quoi p...
 
ASFWS 2011 : CAS, OpenID, SAML concepts, différences et exemples
ASFWS 2011 : CAS, OpenID, SAML  concepts, différences et exemplesASFWS 2011 : CAS, OpenID, SAML  concepts, différences et exemples
ASFWS 2011 : CAS, OpenID, SAML concepts, différences et exemples
 
Le futur de l'authentification webAuthn
Le futur de l'authentification webAuthnLe futur de l'authentification webAuthn
Le futur de l'authentification webAuthn
 
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemples
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemplesCAS, OpenID, Shibboleth, SAML : concepts, différences et exemples
CAS, OpenID, Shibboleth, SAML : concepts, différences et exemples
 
LemonLDAP::NG et le support SAML2 (RMLL 2010)
LemonLDAP::NG et le support SAML2 (RMLL 2010)LemonLDAP::NG et le support SAML2 (RMLL 2010)
LemonLDAP::NG et le support SAML2 (RMLL 2010)
 
OpenSSO Aquarium Paris
OpenSSO Aquarium ParisOpenSSO Aquarium Paris
OpenSSO Aquarium Paris
 
LemonLDAP::NG et le support SAML2
LemonLDAP::NG et le support SAML2LemonLDAP::NG et le support SAML2
LemonLDAP::NG et le support SAML2
 
Sayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexes
Sayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexesSayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexes
Sayeh hiba-karaa-eya-ferjani-maroua-hamzaoui-balkiss-sys-complexes
 
CAS, OpenID, SAML : concepts, différences et exemples
CAS, OpenID, SAML : concepts, différences et exemplesCAS, OpenID, SAML : concepts, différences et exemples
CAS, OpenID, SAML : concepts, différences et exemples
 
Openstack framework Iaas
Openstack framework IaasOpenstack framework Iaas
Openstack framework Iaas
 
Authentification sociale en angular 1.pptx
Authentification sociale en angular 1.pptxAuthentification sociale en angular 1.pptx
Authentification sociale en angular 1.pptx
 
Rapport sécurité
Rapport sécuritéRapport sécurité
Rapport sécurité
 
[JDLL 2016] OpenID Connect et FranceConnect
[JDLL 2016] OpenID Connect et FranceConnect[JDLL 2016] OpenID Connect et FranceConnect
[JDLL 2016] OpenID Connect et FranceConnect
 
OIDC jusque dans les applications mobiles
OIDC jusque dans les applications mobilesOIDC jusque dans les applications mobiles
OIDC jusque dans les applications mobiles
 
LTO Auth
LTO AuthLTO Auth
LTO Auth
 
SOLID : les principes à l’origine du succès de Symfony et de vos applications
SOLID : les principes à l’origine du succès de Symfony et de vos applicationsSOLID : les principes à l’origine du succès de Symfony et de vos applications
SOLID : les principes à l’origine du succès de Symfony et de vos applications
 
Gérer facilement les identités dans le cloud
Gérer facilement les identités dans le cloudGérer facilement les identités dans le cloud
Gérer facilement les identités dans le cloud
 

Secure a REST API for external public access

  • 1. Secure a REST API Thierry GAYET - 01/2024
  • 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.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 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'
  • 20. TOKEN GENERATION $ nano genToken.py #!/usr/bin/env python3 # -*- coding:utf8 -*- from itsdangerous import URLSafeSerializer auth_s = URLSafeSerializer("secret key", "auth") id:int = input(" - Select a number : ") name:str = input(" - Select a product name : ") token = auth_s.dumps({"id": id, "name": name}) print(token) # Examples : # eyJpZCI6NSwibmFtZSI6Iml0c2Rhbmdlcm91cyJ9.6YP6T0BaO67XP--9UzTrmurXSmg # eyJpZCI6NDAsIm5hbWUiOiJzdHJlYW1wcm9iZSJ9.BT6_m8L-MaeVcmEKnTsu55wFev4 # eyJpZCI6IjI1IiwibmFtZSI6InN0cmVhbXByb2JlIn0.uzPor5MlOWYQJ0PDgVbqtkHNfiw data = auth_s.loads(token) print(data["name"]) print(str(data["id"]))
  • 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
  • 24.
  • 26.