Heb je wel eens gebruik gemaakt van een API van Twitter, Facebook of Google? Dan heb je waarschijnlijk te maken gehad OAuth, de technologie die je toestemming verleent om gebruik te maken van die API's.
+
+
Er zijn veel misverstanden over OAuth waardoor het vaak verkeerd begrepen wordt en er veel frictie ontstaat ontstaat tussen de API en de ontwikkelaar. Het is bijvoorbeeld niet ontworpen om enkel mee in te loggen, hoewel het daar wel veel voor gebruikt wordt. Deze week gaan we kijken naar het probleem van authoriseren en hoe OAuth dat oplost.
+
+
We nemen als voorbeeld de Poespas bank. Een simpele website waarmee gebruikers kunnen inloggen met een gebruikersnaam en wachtwoord. Als ze ingelogd zijn zien ze hun huidige saldo. Ze hebben ook een simpele API waarmee gebruikers hun saldo kunnen checken.
+
+
Simpele authenticatie
+
+
Een simpele manier om de saldo API te implementeren is om rechtstreeks je gebruikersnaam en wachtwoord mee te geven in de API request. De server checkt of de inloggegevens correct zijn en geeft de saldo informatie terug van die gebruiker terug. Uiteraard moet dit alles over een beveiligde verbinding gebeuren, maar als dat zo is is het in theorie een veilige oplossing.
+
+
+
+
+
+
Veel echte API's werkte vroeger op deze manier (vaak op basis van HTTP Authentication). En zolang alles over een beveiligde verbinding tussen de gebruiker en de server loopt is alles veilig. De problemen beginnen echter als een derde partij betrokken raakt bij onze API.
+
+
Een startup heeft de BudgetApp ontwikkelt, een nieuwe app die laat zien hoeveel saldo je per maand op je rekening hebt staan. Ze maken gebruik van de Poespas API om het saldo van de gebruiker op te halen. Maar om die API te kunnen gebruiken hebben ze de gebruikersnaam en het wachtwoord van de gebruiker nodig. Op hun inlogscherm vragen ze daarom om de inloggegevens zodat de app goed kan werken.
+
+
+
+
+
+
Het probleem met deze manier van authenticeren wordt nu snel duidelijk: de app krijgt de gebruikersnaam en wachtwoord van de gebruiker in handen. Daarmee kunnen ze niet alleen het saldo kunnen ophalen met de API. Maar ook alle andere dingen die de gebruiker kan zoals bijvoorbeeld inloggen, geld overschrijven en wachtwoord veranderen.
+
+
+
Om deze situatie te voorkomen willen we een autorisatiesysteem waarbij de app wel een sleutel krijgt om de API te gebruiken, maar niet het wachtwoord van de gebruiker zelf. Dat moet strict geheim blijven.
+
+
Enter OAuth
+
+ ...Access token verhaal...
+
+
autorisatie
+
+
Deze site heeft ook een API die te vinden is op: /api/hallo. Die mag je uiteraard alleen gebruiken als je een access token hebt, als je gewoon op de link klikt krijg je een lege 403 pagina (Forbidden). We gaan alle stappen doorlopen om te komen tot de almachtige access token waarmee we de API kunnen aanroepen.
+
+
De eerste stap bij een OAuth provider is om een client aan te maken. Daarmee weet de site altijd wie het is die de API aanroep doet. Voor deze opdracht kan je die aanmaken op deze pagina. Maak je eigen applicatie met de volgende gegevens:
+
+
+
Name: mag je zelf kiezen
+
Client id: mag je zelf kiezen, maar moet wel uniek zijn
+
Client secret: mag je zelf kiezen
+
Client type: Public
+
Authorization grant type: Authorization code
+
Redirect uris: http://example.com/ (mag ook een andere onzin URL zijn)
+
+
+
+
+
+
+
+ Wat is de client_id die je hebt geregistreerd?
+
5 punten
+
+
+
+
Elke OAuth server heeft twee endpoints (lees: URL's): de autorisatie endpoint en de token endpoint. Hieronder zie je de endpoints van een aantal bekende servers:
+
+
+
+
Service
+
Authorization endpoint
+
Token endpoint
+
+
+
Dit vak
+
http://sec1.aii.avans.nl/o/authorize/
+
http://sec1.aii.avans.nl/o/token/
+
+
+
GitHub
+
https://github.com/login/oauth/authorize
+
https://github.com/login/oauth/access_token
+
+
+
Google
+
https://accounts.google.com/o/oauth2/auth
+
https://accounts.google.com/o/oauth2/token
+
+
+
Facebook
+
https://www.facebook.com/dialog/oauth
+
https://graph.facebook.com/oauth/access_token
+
+
+
+
De autorisatie endpoint is de URL waar je de gebruiker heenstuurt om hem te laten inloggen op de website en om op 'Toestaan' te laten klikken. Deze site redirect daarna weer terug naar je eigen site / app met een speciale autorisatie code. De token endpoint is de OAuth API waar we al onze access tokens uit kunnen halen, maar dan hebben we wel eerst die autorisatie code nodig.
+
+
Om te authoriseren hebben we de volgende URL parameters nodig: (documentatie)
+
+
+
response_type: "token" of "code". Met "token" krijg je direct een access token in de redirect URL. Handig als je de API maar 1x hoeft te gebruiken. Minder handig als je de API langer wilt blijven gebruiken, want access tokens blijven vaak niet langer dan een uur geldig. Dan moet je de gebruiker elk uur opnieuw laten inloggen. Met "code" krijg je een autorisatie code die je kan inwisselen voor een speciale refresh_token, daar kan je tot in de oneindigheid nieuwe access tokens mee maken. Voor deze opdracht gebruiken we "code".
+
client_id: Jouw gekozen client id
+
redirect_uri: optioneel, en eigenlijk ook redundant. Want die geef je ook vaak op als je je registreert als client bij de provider. Als de gebruiker op 'Toestaan' heeft geklikt wordt hij naar deze URL teruggestuurt met de autorisatie code of access token
+
scope: optioneel, kan je mee aangeven welke gedeeltes van de API je wilt kunnen gebruiken
+
state: optioneel, een string die je kan meegeven die ook weer wordt teruggestuurd als de gebruiker wordt terug geredirect. Kan handig zijn.
+
+
+
Een voorbeeld van een autorisatie URL is: http://sec.aii.avans.nl/o/authorize/?client_id=(CLIENT_ID)&response_type=code
+
+
+ Autoriseer met je eigen client id. Welke autorisatie code heb je gekregen?
+
5 punten
+
+
+
+
Access tokens in zicht
+
+
Ok, we hebben nu een autorisatie code. Met die code heb je nu een bewijsje dat de gebruiker recentelijk jouw client heeft geautoriseerd. Maar na dat alles hebben we nog steeds niet die albelangrijke access tokens die ons toegang geven tot de API. Om daar aan te komen moeten we onze autorisatie code inwisselen bij de token endpoint voor een refresh token en een access token.
+
+
Dit lijkt allemaal nodeloos complex, waarom geeft OAuth nadat de gebruiker zijn zege heeft gegevens ons niet meteen een refresh_token en een access_token? Waarom moet dat nou weer via een aparte 'autorisatie code'? De reden hiervoor is is dat OAuth ontworpen is rond het principe dat webapplicatie's access_token moeten kunnen krijgen, zonder dat de gebruiker die te zien krijgt. De gebruiker kan niet zelf nieuwe access tokens ophalen omdat hij niet de client_secret heeft.
+
+
Om de access_token en de refresh_token te krijgen moeten we POST requests versturen naar de token endpoint. Testen met POST requests is het handigst om met een tool te doen. In de screenshots maken we gebruik van Postman.
+
+ We moeten de volgende parameters meesturen: (documentatie)
+
+
+
grant_type: Moet de waarde "authorization_code" hebben.
+
code: De autorisatie code die we hebben gekregen van de autorisatie endpoint.
+
+
+
+
+
+ ... Wissel om voor een access token (binnen 60 sec!) ...
+
+ Welke access_token heb je gekregen? 2 punten
+ En welke refresh_token? 2 punten
+
+ Gebruik de access_token om de API /api/hello aan te roepen.
+
+ Welke geheime code is er op de API te downloaden? 5 punten
+
+ ... Refresh ...
+
+
Google
+
+ Calendar API: https://www.googleapis.com/calendar/v3/calendars/secavans@gmail.com/events
+ Refresh token: 1/Capy9gSUUiS3HEWDCrc8AQjSoBg3uPz79JtOvSVw5kk
+
+ ... Wat is de geheime code? 20 punten
+
+
+ Gebruik je eigen Google account om iets uit een Google API te halen. Denk bijvoorbeeld aan je laatst ontvangen gmail mailtje, een overzicht van bestanden op Google Drive,
+
+ Beschrijf alle GET en POST requests die je hebt gedaan om tot de .
+
+
Eigen API
+
+ Maak een kleine webapplicatie waarmee je alle evenementen op je Google calendar kan inzien. Je mag hierbij gebruik maken van een framework.
+ 30 punten
+
+
+
+
+
+
+
+{% endblock %}
diff --git a/views.py b/views.py
index 944d843..7f8d683 100644
--- a/views.py
+++ b/views.py
@@ -8,6 +8,7 @@ from django.contrib.auth.models import User
from django.contrib import messages
from quiz.models import Answer
import oauth2 as oauth, cgi, json, base64, urlparse, subprocess
+from oauth2_provider.views.generic import ProtectedResourceView
import securityquiz.secrets as secrets
import securityquiz.settings as settings
@@ -85,6 +86,7 @@ def save_data(data, user):
answer.save()
def home(request, url):
+ #return HttpResponse('home2')
if not request.user.is_authenticated():
return avans_login(request)
@@ -112,13 +114,17 @@ def home(request, url):
template = 'openssl.html'
elif url == 'bonus':
template = 'bonus.html'
+ elif url == 'oauth':
+ template = 'oauth.html'
else:
return HttpResponseNotFound('404')
return render(request, template, {'answers': answers_dict})
-
+class SecurityApi(ProtectedResourceView):
+ def get(self, request, *args, **kwargs):
+ return HttpResponse("Geheime code: abguvatgbfrrurerzbirnybat")
def sign(request):
if request.method == 'POST':
+ 
+ 
+ 
+