Profesia, Lynx Group, presenta la quinta puntata della serie di master class sulla tecnologia WSO2 di cui è Distributore esclusivo per l'Italia. Il webinar, con la partecipazione straordinaria di WSO2, descrive come implementare nei client l'autorizzazione OAUTH2. Scrivi a contact@profesia.it se stai pensando a una trasformazione digitale per evolvere verso un business agile

2. Iscriviti al gruppo Linkedin WSO2 Italia per entrare nella community italiana,
conoscere la tecnologia WSO2 e condividere strategie di integrazione e use cases

3. Identity Server: Oauth2 lato Client

4. Identity Server: Oauth2 lato Client

5. Identity Server: Oauth2 lato Client

6. Identity Server: Oauth2 lato Client

7. Identity Server: Oauth2 lato Client

8. Identity Server: Oauth2 lato Client

9. Identity Server: Oauth2 lato Client

10. Identity Server: Oauth2 lato Client
Authorization
Code Grant

11. Identity Server: Oauth2 lato Client
Implicit Code
Grant

12. Identity Server: Oauth2 lato Client
Resource Owner
Password
Credentials
Grant

13. Identity Server: Oauth2 lato Client
Client
Credentials
Grant
curl -v -X POST -H "Authorization: Basic <base64 encoded client id:client secret value>" -k -d
"grant_type=client_credentials" -H "Content-Type:application/x-www-form-urlencoded"
https://localhost:9443/oauth2/token
Request
{"token_type":"Bearer","expires_in":2061,"access_token":"ca19a540f544777860e44e75f605d927"}
Response

14. Identity Server: Oauth2 lato Client
JWT Bearer
Grant

15. Identity Server: Oauth2 lato Client
JWT Bearer
Grant
Request
curl -i -X POST -u <CLIENT_ID>:<Client_SECRET> -k -d
'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<JWT>' -H 'Content-Type:
application/x-www-form-urlencoded' https://localhost:9443/oauth2/token
Response
{"token_type":"Bearer","expires_in":3600,"refresh_token":"b1b4b78e2b0ef4956acb90f2e38a8833","access_token":"615ebcc
943be052cf6dc27c6ec578816"}

16. Identity Server: Oauth2 lato Client
OAuth2 Token Validation and Introspection
Iintrospection Endpoint OAuth :
https://localhost:9443/oauth2/introspect
curl introspect:
curl -k -u <USERNAME>:<PASSWORD> -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<ACCESS_TOKEN>'
https://localhost:9443/oauth2/introspect
response:
{"exp":1464161608,"username":"admin@carbon.super","active":true,"token_type":"Bearer","client_id":"rgfKVdnMQnJSSr_pKFTxj3ap
iwYa","iat":1464158008}

17. Identity Server: Oauth2 lato Client
OAuth Token Validation using SOAP Service
WSO2 Identity Server provides a SOAP service to validate the OAuth2 token it has issued, which can be used by the
resource server. This section guides you through calling the SOAP service using the SOAP UI.
Sample: using SoapUI
1. Go to the SOAP UI and give the WSDL location
Service Name: OAuth2TokenValidationService
WSDL location: https://localhost:9443/services/OAuth2TokenValidationService?wsdl

18. Identity Server: Oauth2 lato Client
OAuth Token Validation using SOAP Service

19. Identity Server: Oauth2 lato Client
OAuth2 Token Revocation
The OAuth Token Revocation functionality is available with WSO2 Identity Server and follows this specification
REST endpoint at /oauth2/revoke
The following is an example of the request that needs to be sent to the revocation REST endpoint by OAuth 2.0 client
to revoke a token:
curl -X POST --basic -u "<client id>:<client secret>" -H "Content-Type:
application/x-www-form-urlencoded;charset=UTF-8" -k -d "token=<token to
revoke>&token_type_hint=access_token" https://localhost:9443/oauth2/revoke

20. Identity Server: Oauth2 lato Client
OAuth2 Clients
The OAuth 2.0 specification defines two types of clients based on their ability to maintain the confidentiality of client
credentials as below.
Confidential:
A Confidential client is capable of maintaining the confidentiality of its credentials provided by an authorization
server. For example a web application where only the administrator can get access to the server and see the client
credentials would be a confidential client.
Public:
A public client is not capable of maintaining the confidentiality of its credentials provided by an authorization server.
For example a mobile phone application or a desktop application that has the client secret embedded, could get
cracked, and the secret could be revealed. The same is true for a JavaScript application running in the users browser.
The user could use a JavaScript debugger to look into the application, and see client credentials.

21. Identity Server: Oauth2 lato Client
Web Application
OAUTH2 Client

22. Identity Server: Oauth2 lato Client
User Agent Based Application
OAUTH2 Client

23. Back-channel Authentication and API Authorization
The following implementations are the most common back-channel flows you may come across:
1. Legacy username/password authentication and token-based API authorization
2. OIDC resource owner password grant flow

24. Legacy
username/passwo
rd authentication
and token-based
API authorization

25. OIDC
Authentication
Using Resource
Owner Password
Credentials
Grant Flow

26. Front-channel Authentication and API Authorization
The following implementations are the most common front-channel flows you may come across:
● Legacy identity federation and API authorization
● OIDC implicit grant flow
● OIDC authorization code grant flow
● OIDC authorization code grant flow with Proof Key for Code Exchange (PKCE)

27. Legacy Identity Federation and API Authorization

28. OIDC Authentication Using Implicit Grant Flow

29. OIDC Authorization Code Flow

30. OIDC Authorization Code Flow with PKCE

31. Front-channel Authentication and API Authorization
Pro:
● They provide a single sign-on experience to the users.
● Users provide their credentials only to the IAM system which mitigates possibilities of password leakage to a
great extent.
Cons:
● they involve redirections and therefore do not provide the best possible user experience.
Pros and Cons of front-channel flows

32. Q&A?

33. GRAZIE!!!
Prossimo appuntamento:

34. Contatti
DOVE SIAMO
Milano - Torino - Padova - Roma
TELEFONO
Torino +39-011-0120371
EMAIL
wso2.sales@profesia.it
@