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
Take control of your SAP testing with UiPath Test Suite
#5 WSO2 Masterclassitalia - WSO2 Identity Server, un approccio OAUTH2
1.
2. Iscriviti al gruppo Linkedin WSO2 Italia per entrare nella community italiana,
conoscere la tecnologia WSO2 e condividere strategie di integrazione e use cases
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
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.
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
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)
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