1. Intro - Auth - Authentication & Authorization & SSO
2. OAuth2 in Depth
3. Where does JWT fit in ?
4. How to do stateless Authorization using OAUTH2 & JWT ?
5. Some Sample Code ? How easy is it to implement ?
OAuth 2 is an authorization framework that allows applications to access user data and perform actions on their behalf. It defines flows for applications to request access, and provides short-lived credentials in response. The main roles in OAuth are the resource owner (user), client (application), resource server (API), and authorization server (issues tokens). Common grant types include authorization code, implicit, and client credentials flows. Tokens returned include access and refresh tokens, and OpenID Connect adds optional ID tokens containing user information.
This document discusses authentication and authorization frameworks like OAuth and OpenID Connect. It provides an overview of key concepts like authentication, authorization, roles in OAuth like resource owner, client, authorization server and resource server. It explains the authorization code grant flow in OAuth and how OpenID Connect builds upon OAuth to provide identity features. It also compares OpenID Connect to SAML and discusses Microsoft and TechCello implementations of these specifications.
This 20-minute presentation introduces OAuth through defining it, explaining why it is useful, providing background information, defining key terminology, outlining the workflow, and including a live example. It defines OAuth as a method for users to grant third-party access to their resources without sharing passwords and to grant limited access. It highlights issues with traditional client-server authentication and how OAuth addresses them. The presentation then covers OAuth background, terminology like consumer and service provider, the redirection-based authorization workflow, and concludes with a live example and references for further information.
An introduction to OAuth2 and OpenID Connect intended for a technical audience. This covers terminology, core concepts, and all the core grants/flows for OAuth2 and OpenID Connect
This slide deck gives an introduction to OAuth 2.0, starting with some concepts, explaining the flow plus a few hints. The reminder of the slides are about implementing an OAuth 2.0 server using the Apache Amber library (renamed to Apache Oltu lately). My impression is that many developers shy away as soon as they hear "security" and so I did not only want to talk about the concepts of OAuth 2.0 but also wanted to show how easily you can implement an OAuth 2.0 server ... hope it reduces the fear of contact a bit ... ;-)
The document discusses OAuth 2.0 and how it provides a method for third party applications to access private resources from an API, while allowing the resource owners to authorize access without sharing credentials. It describes the four main roles in OAuth 2.0 - resource owner, client, authorization server, and resource server. It also summarizes the three main authorization flows - authorization code, implicit, and client credentials flows. The document provides details on how each flow works, including the request and response parameters.
OAuth 2 is an authorization framework that allows applications to access user data and perform actions on their behalf. It defines flows for applications to request access, and provides short-lived credentials in response. The main roles in OAuth are the resource owner (user), client (application), resource server (API), and authorization server (issues tokens). Common grant types include authorization code, implicit, and client credentials flows. Tokens returned include access and refresh tokens, and OpenID Connect adds optional ID tokens containing user information.
This document discusses authentication and authorization frameworks like OAuth and OpenID Connect. It provides an overview of key concepts like authentication, authorization, roles in OAuth like resource owner, client, authorization server and resource server. It explains the authorization code grant flow in OAuth and how OpenID Connect builds upon OAuth to provide identity features. It also compares OpenID Connect to SAML and discusses Microsoft and TechCello implementations of these specifications.
This 20-minute presentation introduces OAuth through defining it, explaining why it is useful, providing background information, defining key terminology, outlining the workflow, and including a live example. It defines OAuth as a method for users to grant third-party access to their resources without sharing passwords and to grant limited access. It highlights issues with traditional client-server authentication and how OAuth addresses them. The presentation then covers OAuth background, terminology like consumer and service provider, the redirection-based authorization workflow, and concludes with a live example and references for further information.
An introduction to OAuth2 and OpenID Connect intended for a technical audience. This covers terminology, core concepts, and all the core grants/flows for OAuth2 and OpenID Connect
This slide deck gives an introduction to OAuth 2.0, starting with some concepts, explaining the flow plus a few hints. The reminder of the slides are about implementing an OAuth 2.0 server using the Apache Amber library (renamed to Apache Oltu lately). My impression is that many developers shy away as soon as they hear "security" and so I did not only want to talk about the concepts of OAuth 2.0 but also wanted to show how easily you can implement an OAuth 2.0 server ... hope it reduces the fear of contact a bit ... ;-)
The document discusses OAuth 2.0 and how it provides a method for third party applications to access private resources from an API, while allowing the resource owners to authorize access without sharing credentials. It describes the four main roles in OAuth 2.0 - resource owner, client, authorization server, and resource server. It also summarizes the three main authorization flows - authorization code, implicit, and client credentials flows. The document provides details on how each flow works, including the request and response parameters.
The document provides an overview of the history and development of OAuth standards for authorization. It describes some of the issues with early implementations that prompted the creation of OAuth 1.0, including services storing user passwords and lack of ability to revoke access. OAuth 1.0 introduced signatures to address these issues. OAuth 2.0 replaced signatures with HTTPS and defines common flows for different use cases, including authorization code, implicit, password, and client credentials grants.
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf.
OAuth is an open standard that allows users to grant third-party access to their account information without sharing their passwords. It works by using tokens to authorize specific types of access, allowing users to securely share data between websites or applications. OAuth is widely adopted and brings interconnectivity by allowing users to log into one service using their login credentials from another participating service.
This document provides an introduction and overview of OAuth 2.0. It discusses the key components and actors in the OAuth framework, including clients, protected resources, resource owners, and authorization servers. It describes the major steps of an OAuth transaction, issuing and using tokens. Specifically, it outlines the authorization code grant flow, how clients request and receive access tokens from authorization servers to access protected resources on behalf of resource owners. It also defines common OAuth concepts like scopes, refresh tokens, and authorization grants.
OpenID Connect is a simple identity layer that allows clients like mobile or web apps to verify user identities based on an authentication performed by an authorization server, as well as obtain basic profile information about users. It is built on OAuth 2.0 and defined by the OpenID Foundation. The specification defines core features as well as optional discovery, dynamic registration, session management, and OAuth 2.0 response types. Major companies like Google, Salesforce, and Microsoft have implemented or are deploying OpenID Connect to provide single sign-on for web and mobile clients.
SAML, OAuth 2.0, and OpenID Connect are the three most common authentication protocols. SAML provides authentication and authorization assertions while OAuth 2.0 focuses on authorization. OpenID Connect builds on OAuth 2.0 by adding authentication features and using claims to provide user information. It has a lower implementation barrier than SAML and is well-suited for mobile and API use cases. The document compares the protocols and their applications, security considerations, and history of adoption.
http://www.justin.tv/hackertv/49975/Tech_Talk_1_Leah_Culver_on_OAuth
Tech talk about OAuth, and open standard for API authentication. Originally broadcast on Justin.tv.
This presentation shows what are JSON Web Tokens, explaining about the structure, signature, encryption and how we can integrate this with Authentication/Authorization together with Spring Security.
The link for the project in Github is:
https://github.com/BHRother/spring-boot-security-jwt
The example implements JWT + Spring Security in a Spring-Boot project.
"Json Web Token with digital signature. Modern authentication or authorization. Cookies are bad. Avoid Man-in-the-middle-attack. No need to protect against CSRF. Stateless.
How to integrate the complex use cases in the hyper-connected world with millions of devices and services.
Bhavna Bhatnagar (VigourSoft Technical Advisor and Industry expert) talks about SAML, OAuth, OpenID and what you need to make your place in the complex scenario this presents
OAuth2 is a protocol for authorization that allows clients limited access to user accounts and specifies four methods for obtaining an access token, including the authorization code flow. The authorization code flow involves a client redirecting a user to an authorization server, the user authorizing access, and the authorization server issuing an authorization code to the client, which can then request an access token to access a resource server on the user's behalf, while avoiding exposing the user's credentials directly.
OpenID for Verifiable Credentials is a family of protocols supporting implementation of applications with Verifiable Credentials, i.e. verifiable credential issuance, credential presentation, and pseudonyms authentication.
The DID Report 1: The First Official W3C DID Working Group Meeting (Japan)- D...SSIMeetup
https://ssimeetup.org/did-report-1-first-official-w3c-did-working-group-meeting-japan-drummond-reed-webinar-36/
The DID Report 1 about the First Meeting of the New W3C DID Working Group with Drummond Reed, co-author of the W3C DID specification, and Markus Sabadello from Danube Tech. Headline news in SSI land: this month W3C members approved forming a full W3C Working Group for Decentralized Identifiers (DIDs).
DID spec co-author Drummond Reed has been in Fukuoka Japan for the first official meeting of this new Working Group and he will share highlights of the meeting and the roadmap for taking DIDs to a full Web standard.
What is JWT?
When should you use JSON Web Tokens?
WHAT IS THE JSON WEB TOKEN STRUCTURE?
JWT Process
PROS AND CONS
JWT.IO
Using JSON Web Tokens as API Keys
Smart City is all about being connected - connecting diverse systems for people to connect and interact with the smart city facilities. This presentation highlights what a smart city is and how it is evolving from the time we know our cities, what all it takes for a city to become smart, the challenges involved and the key driver for making cities smart - Internet-of-Things. Do take a walkthrough and feel free to share back your comments, feedback and queries.
The document provides an overview of the history and development of OAuth standards for authorization. It describes some of the issues with early implementations that prompted the creation of OAuth 1.0, including services storing user passwords and lack of ability to revoke access. OAuth 1.0 introduced signatures to address these issues. OAuth 2.0 replaced signatures with HTTPS and defines common flows for different use cases, including authorization code, implicit, password, and client credentials grants.
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf.
OAuth is an open standard that allows users to grant third-party access to their account information without sharing their passwords. It works by using tokens to authorize specific types of access, allowing users to securely share data between websites or applications. OAuth is widely adopted and brings interconnectivity by allowing users to log into one service using their login credentials from another participating service.
This document provides an introduction and overview of OAuth 2.0. It discusses the key components and actors in the OAuth framework, including clients, protected resources, resource owners, and authorization servers. It describes the major steps of an OAuth transaction, issuing and using tokens. Specifically, it outlines the authorization code grant flow, how clients request and receive access tokens from authorization servers to access protected resources on behalf of resource owners. It also defines common OAuth concepts like scopes, refresh tokens, and authorization grants.
OpenID Connect is a simple identity layer that allows clients like mobile or web apps to verify user identities based on an authentication performed by an authorization server, as well as obtain basic profile information about users. It is built on OAuth 2.0 and defined by the OpenID Foundation. The specification defines core features as well as optional discovery, dynamic registration, session management, and OAuth 2.0 response types. Major companies like Google, Salesforce, and Microsoft have implemented or are deploying OpenID Connect to provide single sign-on for web and mobile clients.
SAML, OAuth 2.0, and OpenID Connect are the three most common authentication protocols. SAML provides authentication and authorization assertions while OAuth 2.0 focuses on authorization. OpenID Connect builds on OAuth 2.0 by adding authentication features and using claims to provide user information. It has a lower implementation barrier than SAML and is well-suited for mobile and API use cases. The document compares the protocols and their applications, security considerations, and history of adoption.
http://www.justin.tv/hackertv/49975/Tech_Talk_1_Leah_Culver_on_OAuth
Tech talk about OAuth, and open standard for API authentication. Originally broadcast on Justin.tv.
This presentation shows what are JSON Web Tokens, explaining about the structure, signature, encryption and how we can integrate this with Authentication/Authorization together with Spring Security.
The link for the project in Github is:
https://github.com/BHRother/spring-boot-security-jwt
The example implements JWT + Spring Security in a Spring-Boot project.
"Json Web Token with digital signature. Modern authentication or authorization. Cookies are bad. Avoid Man-in-the-middle-attack. No need to protect against CSRF. Stateless.
How to integrate the complex use cases in the hyper-connected world with millions of devices and services.
Bhavna Bhatnagar (VigourSoft Technical Advisor and Industry expert) talks about SAML, OAuth, OpenID and what you need to make your place in the complex scenario this presents
OAuth2 is a protocol for authorization that allows clients limited access to user accounts and specifies four methods for obtaining an access token, including the authorization code flow. The authorization code flow involves a client redirecting a user to an authorization server, the user authorizing access, and the authorization server issuing an authorization code to the client, which can then request an access token to access a resource server on the user's behalf, while avoiding exposing the user's credentials directly.
OpenID for Verifiable Credentials is a family of protocols supporting implementation of applications with Verifiable Credentials, i.e. verifiable credential issuance, credential presentation, and pseudonyms authentication.
The DID Report 1: The First Official W3C DID Working Group Meeting (Japan)- D...SSIMeetup
https://ssimeetup.org/did-report-1-first-official-w3c-did-working-group-meeting-japan-drummond-reed-webinar-36/
The DID Report 1 about the First Meeting of the New W3C DID Working Group with Drummond Reed, co-author of the W3C DID specification, and Markus Sabadello from Danube Tech. Headline news in SSI land: this month W3C members approved forming a full W3C Working Group for Decentralized Identifiers (DIDs).
DID spec co-author Drummond Reed has been in Fukuoka Japan for the first official meeting of this new Working Group and he will share highlights of the meeting and the roadmap for taking DIDs to a full Web standard.
What is JWT?
When should you use JSON Web Tokens?
WHAT IS THE JSON WEB TOKEN STRUCTURE?
JWT Process
PROS AND CONS
JWT.IO
Using JSON Web Tokens as API Keys
Smart City is all about being connected - connecting diverse systems for people to connect and interact with the smart city facilities. This presentation highlights what a smart city is and how it is evolving from the time we know our cities, what all it takes for a city to become smart, the challenges involved and the key driver for making cities smart - Internet-of-Things. Do take a walkthrough and feel free to share back your comments, feedback and queries.
The document discusses an agile framework for JWT agencies to improve productivity when working on complex projects and integrated services for clients. It proposes assembling a "project squat" of specialists to work as a team from the initial brief through delivery. Their goals are to keep production team "flow" steady by reducing interruptions and adapting to changes. The framework involves discovery workshops to align stakeholders, planning in sprints with clear deliverables, and using kanban boards and rituals like stand-ups for teams to own their work and optimize efficiency through iterations.
This presentation is about my talk on TDC 2015. It is an invite for you to understand and know more about reactive programming and vert.x to develop your microservices.
References:
Vertx Documentation > http://vertx.io/docs/
Martin Fowler > http://martinfowler.com/articles/microservices.html
Reactive Manifesto > http://reactivemanifesto.org
OpenID is a decentralized protocol that allows users to log in to multiple websites using a single digital identity. It allows users to maintain a single username and password that can be used to access any website that accepts OpenID logins. When a user logs in to a website using OpenID, they are redirected to their OpenID provider to authenticate, and then sent back to the website. This allows for single sign-on across multiple sites without needing separate credentials for each site.
This document discusses using JSON Web Tokens (JWT) for authentication with AngularJS. It begins with an overview of JWT, explaining that they are composed of a header, payload, and signature. The payload contains claims about the user like ID, expiration, and scope. JWTs can be issued by a server and verified by the signature without needing a database lookup. The document then discusses storing and transmitting JWTs securely in cookies rather than local storage due to cross-site scripting vulnerabilities. It provides examples of using JWTs to determine if a user is logged in and if they have access to a particular view in Angular using resolves, events, and checking the token payload.
This document appears to be an agenda for a bootcamp on OpenID being presented by Simon Willison and David Recordon. The summary includes:
1) The bootcamp will provide an introduction to basic OpenID concepts, how to create and use an OpenID, discuss adoption history and status, and address security concerns.
2) It will also cover security solutions for OpenID, innovative uses of OpenID in code, and include a question and answer session.
3) OpenID is presented as a decentralized single sign-on mechanism that solves issues like having too many passwords, username squatting, and scattered online profiles across many sites. Users can claim and prove ownership of an OpenID URL for authentication
Following topic were discussed in the slide:
1. What is a Bot exactly?
2. Microsoft Bot in Azure
3. Introducing Microsoft Bot Framework
4. 1000 feet overview
5. Building a useless Bot
6. Building a productive Bot
DEMO
7. Bot Connector and Message
This document discusses OpenID, an open standard for decentralized authentication on the web. It notes some problems with traditional username and password systems like passwords being hard to manage and user databases being vulnerable to theft. OpenID provides a solution by allowing users to authenticate using a URL of their choice, like a personal domain name, rather than having separate usernames and passwords for each site. When authenticating with a new site, OpenID verifies the user's identity through their OpenID provider rather than the site directly. The document provides examples of how OpenID works and can be implemented using libraries like Net::OpenID::Consumer in Perl. It also addresses questions like how to choose an OpenID provider and maintain multiple personas.
Modern Security with OAuth 2.0 and JWT and Spring by Dmitry BuzdinJava User Group Latvia
Have you ever wondered how single-sign-on on sites like Google and Facebook works? Are you a fan of stateless application architectures? Do you want to learn how to put together a modern security approach for your next Spring Boot project? If the answer is yes, to anything above, then this session is for you. Dmitry will explain what is OAuth 2.0 and JWT, why are they popular, and how to integrate them in Java project.
Microservices for the Masses with Spring Boot, JHipster, and JWT - Rich Web 2016Matt Raible
Microservices are all the rage and being deployed by many Java Hipsters. If you’re working on a large team that needs different release cycles for product components, microservices can be a blessing. If you’re working at your VW Restoration Shop and running its online store with your own software, having five services to manage and deploy can be a real pain. Share your knowledge and experience about microservices in this informative and code-heavy talk.
We’ll use JHipster (a Yeoman generator) to create Angular + Spring Boot apps on separate instances with a unified front-end. I’ll also show you options for securing your API gateway and individual applications using JWT. Heroku, Kubernetes, Docker, ELK, Spring Cloud, Stormpath; there will be plenty of interesting demos to see!
The document discusses stateless authentication using OAuth 2.0 and JSON Web Tokens (JWT). It begins with an introduction to OAuth 2.0, including its roles, common grant types like authorization code and implicit grants. It then discusses how JWT can be used to achieve statelessness by encoding claims in the token that are signed and can be verified without storing state on the authorization server. The document provides examples of what a JWT looks like and considerations for using JWT in applications.
Game On: Everything you need to know about how games are changing the worldJeremy Johnson
Gaming is at a tipping point, never before have games effected our day-to-day lives in such a substantial way. From entertaining yourself on the subway with Angry Birds, to solving the world's greatest problems - gaming is quickly becoming a mainstream way to explore, communicate, connect, and work.
With "Game On" Jeremy Johnson will take you on a tour of gaming trends - which includes everyone's favorite gaming buzz words: gamification, gameful, game layer, gamestorming, game mechanics, gameplay, game theory and good old video games. How's that for a extra helping of games? Let's top it off with a Call of Duty deathmatch - who's game?
This presentation was given at Big Design 2011 in Dallas Texas. #bigd11
This talk is about how to secure your frontend+backend applications using a RESTful approach. As opposed to traditional and monolithic server-side applications (where the HTTP session is used), when your frontend application is running on a browser and not securely from the server, there are few things you need to consider.
In this session Alvaro will explore standards like OAuth or JWT to achieve a stateless, token-based authentication using frameworks like Angular JS on the frontend and Spring Security on the backend.
Video available at https://skillsmatter.com/skillscasts/6058-stateless-authentication-for-microservices
AWS re:Invent 2016: NEW LAUNCH! Introducing Amazon Lex (MAC304)Amazon Web Services
Amazon Lex is a service for building conversational interfaces into any applications using voice and text. With Lex, the same deep learning engine that powers Amazon Alexa is now available to any developer, enabling you to build sophisticated, natural language chatbots into your new and existing applications. Amazon Lex provides the deep functionality and flexibility of natural language understanding (NLU) and automatic speech recognition (ASR) to allow you to build highly engaging user experiences with lifelike, conversational interactions. In this introductory session, find out how Lex provides deep functionality and flexibility to empower you to define entirely new categories of products that are made possible through conversational interfaces.
Presentation from MeetJS Kraków February 2017.
Will 2017 be a year of Voice Assistants? Let's ask Alexa from Amazon to hear what she thinks about that!
During a presentation, I will show you how to teach Amazon Alexa new skills. I will not only briefly cover Amazon AI Stack: AWS Lambda, AWS Lex and AWS Poll, but also Node.js toolset which will encourage you to start experimenting yourself.
PS: Alexa is a bit shy, so please don't make a noise during a presentation
OpenID is a decentralized authentication system that allows users to log in to multiple websites using a single digital identity. It solves problems like having too many usernames and passwords to remember across different accounts. OpenID uses URLs as unique identifiers and allows users to verify their identity by logging in through a trusted third party identity provider such as Google or AOL. While it outsources security to third parties, proponents argue that common practices like password reset emails already do this. OpenID allows for easier management of multiple online identities and personas.
Successful free to play games are a brew of persuasion techniques designed to achieve fast engagement. Here’s a short list and lots of examples of the most notorious persuasive methods and psychological tactics that are used in games you play and love.
The document discusses stateless authorization using OAuth2 and JSON Web Tokens (JWT). It begins with an introduction to authentication, authorization, and single sign-on (SSO). It then provides an in-depth explanation of OAuth2 actors, flows, and grant types. The Authorization Code Grant flow and Implicit Grant flow are explained in detail. Finally, it introduces JWT and why it is a suitable standard for representing OAuth2 access tokens since it meets the requirements and libraries are available.
The document discusses OAuth 2.0 and how it addresses issues with traditional approaches to authorizing third party access to user accounts and resources. It provides an overview of OAuth 2.0 concepts like authorization grants, access tokens, refresh tokens, and the roles of the client, resource owner, authorization server and resource server. It then describes the authorization code grant flow and client credentials flow in more detail through examples. The goal is to explain how OAuth 2.0 works and how it can be used to securely authorize access to resources while avoiding the risks of directly sharing user credentials.
Microservice security with spring security 5.1,Oauth 2.0 and open id connect Nilanjan Roy
This document provides an overview of microservice security using Spring Security 5.1, OAuth 2.0, and OpenID Connect. It defines OAuth 2.0 and its authorization framework, describing how applications can be authorized to access user data. It outlines the authorization code grant flow and other grant types, including how applications register and use client IDs and secrets. JSON Web Tokens are discussed as an access token format. OpenID Connect is described as extending OAuth 2.0 to provide authentication via ID tokens. Key components like access tokens, refresh tokens, and the client credentials flow are also summarized.
This document provides an overview of OAuth2 as an authorization standard. It describes the key concepts in OAuth2 including the resource owner, client, authorization server, access tokens, refresh tokens, and different grant types (authorization code, implicit, resource owner password, client credentials). It provides examples of OAuth2 flows and demonstrates some implementations.
OAuth 2.0 - The fundamentals, the good , the bad, technical primer and commo...Good Dog Labs, Inc.
OAuth 2.0 seems to be a comprehensive framework for authorizing access to protected resources, but is it really? We can argue that OpenID Connect will make it enterprise ready, but level of adoption in the enterprise is yet to be seen. This primer describes the framework fundamentals,the good, the bad, and common OAuth 2.0 flows.
OAuth2 is an authorization frame to perform app authorization to access resources.
The process is as below-
1. App sends authorization request.
2. API service provides auth code.
3. Application sends auth code with API gateway to issue access token.
4. Access token is used to access restricted resources.
5. Refresh token is used to renew access token.
OAuth2 is a protocol for authorization that allows clients to access user resources stored on a resource server. It separates the client application from the resource owner credentials. The authorization code flow involves a client redirecting a user to an authorization server, the user authenticating and authorizing access, and the authorization server returning an authorization code to the client which can then request an access token to access protected resources from the resource server on the user's behalf, without exposing the user's credentials directly. This flow allows for single sign-on across microservices and fine-grained authorization of delegated access to resources.
OAuth2 Implementation Presentation (Java)Knoldus Inc.
The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. It is commonly used in scenarios such as user authentication in web and mobile applications and enables a more secure and user-friendly authorization process.
APIs are now the standard entry point to the majority of newly created ‘back-end’ functionality. These APIs exist to provide not only a standardized, structured way to access the required features or functions, but also to act as ‘gatekeepers’, ensuring appropriate security, auditing, accounting etc. Security is always underpinned by identity and as such, APIs need to know if not who is accessing them, what is the context in which they are being accessed.
Oauth 2.0 Introduction and Flows with MuleSoftshyamraj55
Learn about the basics of OAuth 2.0 and the different OAuth flows in this introductory video. Understand how OAuth works and the various authorization mechanisms involved.
Microsoft Graph API Delegated PermissionsStefan Weber
Slidedeck presented during a webinar i held on13th December 2023 about how to consume Microsoft Graph API using user level permissions.
Webinar Recording https://youtu.be/2cSsg5ws1H4
Slides for my presentation about OAuth, going in depth in the details of the Authorization Code Grant and PKCE, also describing several security threats to OAuth
Using ArcGIS with OAuth 2.0 - Esri DevSummit Dubai 2013Aaron Parecki
The document provides an overview of OAuth 2.0 authentication and authorization when using ArcGIS. It discusses the problems with traditional password authentication, defines key concepts like resource owner, server, and client. It then covers the different OAuth 2.0 grant types like authorization code for web servers, implicit for browsers and mobile, and client credentials for applications. It provides examples of implementing each grant type and making API requests with the returned access and refresh tokens.
Authentication is the process of verifying a user's identity, while authorization determines what permissions and access levels a user has. Common authentication methods for APIs include basic authentication, bearer tokens, API keys, OAuth 2.0, and OpenID Connect. OAuth 2.0 allows users to grant third party applications access to their account without sharing their credentials. It involves the issuance of tokens that applications use to make API calls. OpenID Connect builds upon OAuth 2.0 to provide authentication for APIs as well by exchanging tokens that contain user identity claims.
OAuth 2.0 is a framework that allows third-party applications to access private resources from an HTTP service, such as photos, videos, contacts, or calendar entries, without requiring end users to share their passwords. It provides authorization flows for web, desktop, mobile and native applications to obtain limited access to these resources without exposing the user's login credentials. This allows individual users to control which third-party applications they trust to access their private data and revoke consent at any time.
"OAuth has become a highly influential protocol due to its swift and wide adoption in the industry. The initial objective of the protocol was specific: it serves the authorization needs for websites. However, the protocol has been significantly repurposed and re-targeted over the years: (1) all major identity providers, e.g., Facebook, Google and Microsoft, have re-purposed OAuth for user authentication; (2) developers have re-targeted OAuth to the mobile platforms, in addition to the traditional web platform. Therefore, we believe that it is necessary and timely to conduct an in-depth study to demystify OAuth for mobile application developers.
Our work consists of two pillars: (1) an in-house study of the OAuth protocol documentation that aims to identify what might be ambiguous or unspecified for mobile developers; (2) a field-study of over 600 popular mobile applications that highlights how well developers fulfill the authentication and authorization goals in practice. The result is really worrisome: among the 149 applications that use OAuth, 89 of them (59.7%) were incorrectly implemented and thus vulnerable. In the paper, we pinpoint the key portions in each OAuth protocol flow that are security critical, but are confusing or unspecified for mobile application developers. We then show several representative cases to concretely explain how real implementations fell into these pitfalls. Our findings have been communicated to vendors of the vulnerable applications. Most vendors positively confirmed the issues, and some have applied fixes. We summarize lessons learned from the study, hoping to provoke further thoughts about clear guidelines for OAuth usage in mobile applications"
(Source: Black Hat USA 2016, Las Vegas)
The document discusses OAuth2 and the authorization code flow. OAuth2 is a protocol for authorization that allows clients to obtain limited access to user accounts and reduces the scope of access. It involves four main actors: a resource owner (user), client app, authorization server, and resource server. The authorization code flow involves the client redirecting the user to the authorization server to log in, the user authorizing access, and the authorization server issuing an authorization code to the client, which can then request an access token to access protected resources from the resource server on the user's behalf.
An introduction to OAuth 2.0 from a Salesforce perspective to establish the foundations of OAuth 2.0. Discusses the key concepts of Authentication and Authorization and distinguishes the two. Also discusses Open ID connect.
.NET Core, ASP.NET Core Course, Session 19aminmesbahi
The document provides an introduction to ASP.NET Core Identity and OAuth 2.0 authorization. It discusses Identity topics like user registration, sign in, the database schema, and dependencies. It also covers OAuth concepts like roles, tokens, registering as a client, authorization flows, and security vulnerabilities. The document is an introduction and overview of key Identity and OAuth concepts for a .NET Core training course.
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/06/building-and-scaling-ai-applications-with-the-nx-ai-manager-a-presentation-from-network-optix/
Robin van Emden, Senior Director of Data Science at Network Optix, presents the “Building and Scaling AI Applications with the Nx AI Manager,” tutorial at the May 2024 Embedded Vision Summit.
In this presentation, van Emden covers the basics of scaling edge AI solutions using the Nx tool kit. He emphasizes the process of developing AI models and deploying them globally. He also showcases the conversion of AI models and the creation of effective edge AI pipelines, with a focus on pre-processing, model conversion, selecting the appropriate inference engine for the target hardware and post-processing.
van Emden shows how Nx can simplify the developer’s life and facilitate a rapid transition from concept to production-ready applications.He provides valuable insights into developing scalable and efficient edge AI solutions, with a strong focus on practical implementation.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...Zilliz
Join us to introduce Milvus Lite, a vector database that can run on notebooks and laptops, share the same API with Milvus, and integrate with every popular GenAI framework. This webinar is perfect for developers seeking easy-to-use, well-integrated vector databases for their GenAI apps.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
Stateless Auth using OAUTH2 & JWT
1. www.mobiliya.com
Stateless Auth using OAUTH2 & JWT
Gaurav Roy, @MobiliYa
gaurav-roy-2457635
opengauravroy
- Spread the Knowledge, Initiative
- Jan 4th 2017
2. 2
Agenda
1. Intro - Auth - Authentication & Authorization & SSO
2. OAuth2 in Depth
3. Where does JWT fit in ?
4. How to do stateless Authorization using OAUTH2 & JWT ?
5. Some Sample Code ? How easy is it to implement ?
3. 3
What is Authentication & Authorization ?
Authentication
Is the user, really who he claims to be?
For eq: Login using email + password
4. 4
What is Authorization?
Authorization
Is this “authentic” user, allowed to do Operation “X” on our system?
For eq: Whether logged in user, can upload photos?
Can user access the resource?
5. 5
What is SSO?
SSO : Single Sign On
User has same credentials across multiple sites.
(maybe achieved via Federation concept – same identity across different sites)
For eq:
Stackoverflow trusts Google to do a good job at authentication.
Stackoverflow implements SSO with Google-ID. Google User authentication works on stackoverflow
6. 6
The Problem Statement
“SSO & Federation”
using “Authentication & Authorization”
“across different systems”
needs
“Standards”
7. 7
Enter OAuth2
“OAuth2 is an Open standard for Authorization”
Note: There are others too
But all the big guys in previous page implement OAuth2
(Facebook, Google, Yahoo, Twitter)
Authentication can have its own protocol.
https://tools.ietf.org/html/rfc6749
8. 8
What are popular SSO going around?
For Federation,
Accounts market share matters. NOT STANDARDS
Would you Federate with an authentication service that has 5 users or 50 million ?
Hence, dev prefer to federate with
Google, Facebook, Twitter – all do OAuth2
Reason: Usually, probability of a user already having account higher here.
9. 9
Can I implement my OAuth2 service too ?
You could implement your own service and ask other to work with your OAuth2 spec.
NOTHING STOPPING THAT! IT’S A LEVEL FIELD.
Your app could be
here too ?
14. 14
OAuth2 – “Authorization Server”
A Server
Authenticates the resource owner
Knows username/password of the resource owner
Issues access tokens on behalf of resource owner
15. 15
OAuth2 – “Resource Server”
A Server
Hosts the resource (owned by resource owner)
Provides the resource on validation of the resource
16. 16
OAuth2 – “Access Token”
A Protected Object
Contains information regarding identity and privileges
associated with a user account
Issued by the “Authorization Server”
17. 17
OAuth2 Actors “Recap”
•Validates access token
•Provides resource to client
app
•Validates credentials
•Provides access token
representing the Resource
Owner
•Wants
•Access token from
Authorization Server
•To access Resource on
Resource Server
•Owns/Delegates
•Credentials to Access the
Resource
•Can
•Generate access token
from Auth Server
Resource
Owner
Client
App
Resource
Server
Auth
Server
18. 18
What are we trying to do with OAuth2?
A “user” (resource owner),
who has an account on “Auth Server” &
who has a resource on “Resource Server”
Delegates access privilege to a “Client” (app)
using a token generated by the “Auth Server”
To access the Resource on “Resource Server”
19. 19
OAuth2 – Main Value Add
Resource Owner
Resource Server
Resource Server has no information
regarding the credentials of the
Resource owner
But can still give him or his clients access
20. 20
When do you need OAuth2?
1. AuthServer :
Your Service wants to implement Identity Management and expose APIs for other
services to use your identity
2. Client :
Your Service wants SSO with Google, Office365, etc or a Proprietary Auth Server
3. Resource Server:
Your Service wants to expose Resources but would like authentication to happen with
another service (internal or external)
4. Resource Server:
Your big Service wants to split into multiple Services (aka micro-services) and would like
SSO & Authorization checks between micro-services.
21. 21
Setup of OAuth2 [one time setup]
Client (App) Registration
One time only, for every Client App.
Usually a registration form in the developer or API section of AuthServer website
Client App will provide following to Auth Server (or more)
1. App Name [shows resource owner]
2. App Website URI
3. Redirect URI
Auth Server will provide following to Client
1. Client Id [publicly exposed]
2. Client Secret [should be protected]
22. 22
Authorization Grant Flows [daily operation]
4 Types of Grant Flows/Types Available for OAuth2 [can support one/more]
1. Authorization Code Grant
2. Implicit Grant
3. Resource Owner Credentials
4. Client Credentials
23. 23
OH GOD! Which Grant Flow to use When?
Cheat Sheet [guideline, not a MUST]
Auth Code Grant: 3rd Party or Web Server Apps
Implicit: 3rd Party Mobile / Web Apps (no backend)
Resource Owner Creds: Apps owned by the Auth Server company
Client Credentials: NO UI Backend - Micro-services API Access
24. 24
Flow #1: Auth Code Grant Flow
3rd Party or Own Web Apps (with server components)
25. 25
Flow 1.1 Code Grant Flow : Auth Code Request
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
26. 26
Flow 1.1 Code Grant Flow : Auth Code Request
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
response_type = code
[indicates the Auth Code Grant Flow]
27. 27
Flow 1.1 Code Grant Flow : Auth Code Request
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
client_id = id
[which client app is initiating the flow
client id received in setup flow]
28. 28
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
Flow 1.1 Code Grant Flow : Auth Code Request
redirect_uri = uri
[user is redirected to this uri after
authentication – success or failure]
30. 30
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
2. SHOW Login & Consent Pages
[accept user creds]
[scope and app approval from user]
Flow 1.2 Code Grant Flow : User Consent
Auth server
1. Validates User Creds
2. Takes Consent on Client + Scope
31. 31
Flow 1.2 : Code Grant Flow : User Consent
Deciphered
from Client ID
Deciphered
from Scope
User Consent
[will typically look like this]
32. 32
Flow 1.3 : Code Grant Flow : Auth Code
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authserver/authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
2. SHOW Login & Consent Pages
[accept user creds]
[scope and app approval from user]
OK
3. redirect_uri/?code=AUTHORIZATION_CODE
Auth server
1. Sends “Auth Code” to the Client
(super-limited time code)
2. Contents of Code – can be anything
33. 33
Flow 1.4 : Code Grant Flow : Access Token Request
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authserver/authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
2. SHOW Login & Consent Pages
[accept user creds]
[scope and app approval from user]
OK
3. redirect_uri/?code=AUTHORIZATION_CODE
4. Access Token Request
authserver/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL
Access Token Request
1. Code – identifies – scope, user, client
2. Client ID/Secret – identifies the client
34. 34
3. Get Resource (access-token)
4. Resource
Flow 1.5 : Code Grant Flow : Access Token + Refresh Token
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Code Request
authserver/authorize?
response_type=code&
client_id=ID&
redirect_uri=URL&
scope=PHOTOS
2. SHOW Login & Consent Pages
[accept user creds]
[scope and app approval from user]
OK
3. redirect_uri/?code=AUTHORIZATION_CODE
4. Access Token Request
authserver/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL
5. token Transfer
{"access_token", "refresh_token"
,"scope":"read","
"info":{auth server defined user info}}
1. Access Token : Token to access api
2. Refresh Token : Token to refresh
access token on expiry
• Refresh token is optional and
MUST not be decode-able
35. 35
Flow #2: Implicit Grant
No Auth Code – directly get a token
Basically, we don’t trust client to keep client-secret secure.
36. 36
Flow 2.1: Implicit Grant Flow : Auth
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Token Request
authserver/authorize?
type=token&
client_id=ID&
redirect_uri=URI
&scope=photos
1. ClientID : identifies the client
2. Refresh URL : redirect url
37. 37
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Token Request
authserver/authorize?
type=token&
client_id=ID&
redirect_uri=URI
&scope=photos2. SHOW Login & Consent Pages
[accept user creds]
[scope and app approval from user]
OK
3. token Transfer
{"access_token"}
3. Get Resource (access-token)
4. Resource
Flow 2.2 & 2.3: Implicit Grant Flow : Auth
1. Access token is transferred
38. 38
Flow 2: Implicit Grant
Did you notice the flow ?
“has one less leg” – no auth code
“has no client secret”
“has no refresh token”
39. 39
Flow 2: Implicit Grant
Why is Implicit Flow so small in comparison to Code Grant ?
For JavaScript Front ends – cannot keep a secret (client-secret or refresh-token)
Used for Limited time user sessions
Requires Cross Origin Resource Sharing (CORS)
Client has onus to prevent CSRF (Cross site Request forgery)
So, in a sense it maybe less secure for the Resource Server
40. 40
Flow 2 : Implicit Flow - CSRF
How is implicit Flow vulnerable to CSRF?
1. Attacker (Resource Owner) loads a Client Website
2. Client calls Authorize to initiate implicit flow on the Auth Server
3. Attacker is redirected to the Auth Server, for credential entry in order to authorize access
4. Instead, Attacker traps/prevents this request and saves the URL
5. Attacker gets Victim (Resource Owner) to visit the saved URL.
6. If Victim is logged-in to the Auth Server with victim’s account,
then victim credentials are used to issue an access token
7. Now attacker on the client is authorized to access resource owner account on the resource server
Phishing
Cross-site
Request Forgery
41. 41
Flow 2 : Implicit – CSRF
How to prevent CSRF in Clients ?
1. Attacker (Resource Owner) loads a Client Website
2. Client creates a state parameter (some unique value based on Attackers userinfo)
3. Client calls Authorize to initiate implicit flow on the Auth Server
(passes the state parameter along with request)
4. Attacker is redirected to the Auth Server, for credential entry in order to authorize access
5. Instead, Attacker traps/prevents this request and saves the URL
6. Attacker gets Victim (Resource Owner) to visit the saved URL.
7. If Victim is logged-in to the Auth Server with victim’s account,
then victim credentials will be used to issue an access token
8. Client regenerates the state parameter based on the current user. Since, they don’t match, the
token will be rejected.
9. Now attacker on the client is authorized to access resource owner account on the resource server
42. 42
Flow 2 : Implicit Vs Auth Code Grant
Auth Code Grant – access token is never generated for a CSRF attack (auth code is a limited time code)
Client can reject the attacker at the Auth Code level.
Hence Auth Code Grant, it’s a little easier to secure than Implicit Grant
43. 43
Flow #3: Resource Owner Credentials
Only for really trusted clients [owned by Auth/Resource server]
For eq: Mobile Apps of a web service
44. 44
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Token Request
authserver/authorize?
type=password&
client_id &
client_secret &
redirect_uri &
username & password&
2. token Transfer
{"access_token" + refresh token}
1. Pass Creds (username, pass)
3. Get Resource (access-token)
4. Resource
Flow 3.1 & 3.2: Credential Grant
1. Trusted client (client id + secret)
2. Resource owner trusts client with
credentials
3. Auth Server gives tokens based on
client secret, password.
45. 45
Flow #4 : Client Credentials
Micro-services in trusted network
belonging to the same website as resource server
Data access not related to a user
46. 46
Resource
Owner
Client
Auth
Server
Resource
Server
1. Auth Token Request
authserver/authorize?
type=client_credentials&
client_id &
client_secret &
scope
2. token Transfer
{"access_token"}
3. Get Resource (access-token)
4. Resource
Flow 4: Client Credentials
1. Access token sent based on client
credentials (of micro-service)
2. Refresh token is not recommended as
Micro-service can always request for
new access-token again
48. 48
Access & Refresh Token
Access Token
Can be of Any format that the Auth Server likes.
MAY have information decodeable by the clients
Refresh Token
Can be of Any format that the Auth Server likes.
MUST NOT have information readable by the clients
49. 49
Access Token Requirements in OAuth2
OAuth2 Access Token (aka Bearer Token)
A Few Requirements
1. Bearer token needs to be protected in storage and transport
2. Any party in possession of bearer token can use it to access associated resource.
3. Only Auth server can generate a valid bearer token
4. Anyone can validate a bearer token (taking some help from the Auth Server)
50. 50
One Available Token Standard : JWT (aka “jot”)
Rather than defining your own token - use a standard
Advantage : Libraries available for JWT + OAuth2
JWT : Set of Claims (protected information) encoded in a json object
Claims maybe digitally signed and/or encrypted (why would you not?)
Full Form “JSON Web Token”
JWT RFC : https://tools.ietf.org/html/rfc7519
51. 51
Why choose JWT?
JWT implementations exist
for Clojure, .NET , Go, Haskell, Python, Node.js, Java, JavaScript, Lua, Perl, PHP, Ruby, Rust, S
cala, Elixir.
That’s most of the Server programming languages going around TODAY.
52. 52
Structure of a JWT Token
Header : Json (plaintext) Algorithm used for encoding claims.
Can be none, if not encoded.
Could select JWS (signed) or JWE (encrypted)
Claims : Json (encoded) • Resource owner information
• Token issues information
• When is this token valid?
• What other info/privileges/scopes etc the token
has? (fields completely flexible)
Signature: Hash { Header + Claims + Secret}
53. 53
A. JWT Header
{ “typ” : “JWT”,
“alg” : “HS256” }
Algorithm chosen for
encoding and signing
A lot of them available
{optionally, authserver can put own pairs in header}
54. 54
Which Keys to use for Access & Refresh Tokens
Access Token - use a Public/Private Key Pair
Others would like to decode your token
Public Key should be accessible to all interested.
Refresh Token - use a Private/secret key
MUST be encrypted using a salt or a private key.
Public key of refresh token should not be queryable.
Why? – Refresh token is used to generate an access token –
No info useful in it, except for the Auth Server.
Only Auth Server should decode refresh key.
55. 55
B. JWT Claims / Payload
{ "iss":“oauth2.mobiliya.com",
“sub” : ”Roy’s Access-token”,
"exp":1300819380,
“iat” : 1300803380,
“nbf” : 1300803380,
“jti” : “8973-r38893-288346834”,
========================
“email” : roy@mobiliya.com,
“name” : “Gauav Roy”,
“access” : [ “photos”, “videos” ]
}
Registered Claims (predefined by JWT)
1. iss – Issuer?
2. sub – what is in this token?
3. exp – expires at?
4. iat – issued at
5. nbf – token not valid before
6. jti – jwt unique id
========================
Private claims
- Anything that the client, resource
server or auth server requires.
- Keep information regarding the user,
scope of the token, user attributes etc.
56. 56
B. JWT Registered & Private Cliams
Standardized claims
Predefined names
Related to JWT
Private (Free form) Claims
Anything that you would like to use?
This is a great way to send various pieces of information related to the user, authorization
or scope
57. 57
C. JWT Signature
HMAC(
(base64Encode(header) +
“.” +
base64Encode(claims)),
secret
)
JWT could be signed with
• Public/Private Key pair
• Secure has based on Salt
Algorithm for signing based on the “typ” field in JWT Header
58. 58
Final JWT Token – Base64 Encoded
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJpc3MiOiJvYXV0aDIubW9iaWxpeWEuY29tIiwic3ViIj
oiUm95J3MgQXV0aCBUb2tlbiIsImV4cCI6MTMwMDg
xOTM4MCwiaWF0IjoxMzAwODAzMzgwLCJuYmYiOjEz
MDA4MDMzODAsImVtYWlsIjoiZ2F1cmF2LnJveUBtb2
JpbGl5YS5jb20iLCJuYW1lIjoiR2F1cmF2IFJveSJ9.
gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
JWT HEADER
JWT CLAIMS / PAYLOAD
JWT SIGNATURE
JWT Sections are separate by “dot” .
Typically, everyone uses
1. HMAC with SHA-256 (HS256) and
2. RSA signature with SHA-256 (RS256).
Have some fun, decode above token at : https://jwt.io/
59. 59
Bonus – JWT Protects against CSRF
Auth Server Resource
Server
Attacker
(Client)
Get Auth Token
(with client-id)
User Consent URL
User Consent URL
OK, giving consent
JWT access token
(with user = victim, client = attacker)
Victim
(Res owner)
Client decodes token to
understand that the user of client
and user on token dont match
Auth Server encodes claims
JWT Private claims achieves
state required to foil CSRF
attacks.
Without JWT, this would need
to be specifically placed by the
client in the header and
reflected back by the server.
STANDARDS MAKE LIFE
EASY AGAIN
61. 61
Monolithic Server – Auth Session Mgmt
Identity Mgmt
+ Authentication
Content Mgmt
User Settings Analytics
Billing & Order
Mgmt
Load
Balancer
Router
Clients
Clients
All Business Logic/Data on one server/DB
- Easy to share a session / authentication info
- Use a DB, share in memory
62. 62
Micro-services Stack Identity Mgmt
+ Authentication
Content Mgmt
User Settings
Analytics
Billing & Order
Mgmt
Load
Balancer
Router
Clients
Clients
Business Logic/Data on different machines/DB
- Need to communicate to share a session or
authentication info
63. 63
What is statefulness?
Client – Server need to communicate using a variety of packets.
Server needs to maintain state of the session with the client.
Easier when the server is a “monolith”
Hard when the server is a set of “micro-services”
Micro-services : Session is distributed. Authorization is distributed
64. 64
JWT to the rescue
Auth Statelessness
Remember – Private Claims
Private Claims : “Can send arbitrary pieces of information”
DON’T STORE the token or give api to other micro-services to get info from Token
Encode JWT to transfer the information for you
User info
Roles of the user
Access Rights
Whatever you need to transfer from the Auth Server to Resource Server
Information / State is being transferred without any api
65. 65
Old Style Auth : without a OAuth2 & JWT state transfer ?
Client
Auth
Server
Resource
Server
1. Authenticate
(some flow)
access token
save token,
userinfo in DB
GET /resource/resourceid {access-token}
give user for token,
give his role
give his billing
give info
Read token,
session DB
return Resource
Before OAuth2 or JWT the
Resource server would
need to go to the Auth
server to validate the
token and get a lot of
information regarding the
user (resource owner)
66. 66
New Style : Stateless Auth using OAUTH2 + JWT
Client
Auth
Server
Resource
Server
1. Authenticate
(some flow)
access token
(encoded with resource owner info)
save token,
userinfo in DB
GET /resource/resourceid {access-token}
give user for token,
give his role
give his billing
give info
Read token,
session DB
return Resource
Locally
1. Validate the token
2. Extract user Info
Advantages:
1. No state DB in Auth server
2. No load on Auth server for
validation of access-token
3. No load on Auth server for
retrieval of resource owner info
4. Lesser latency
67. 67
Section #5 : How easy is OAuth2 with JWT
Lets try some code with Java Spring
68. 68
OAuth2 (using Spring Boot)
Would really advise https://spring.io/guides/tutorials/spring-boot-oauth2/
It will take you exactly 15 mins to
Write a OAuth2 client with SSO with Facebook & Github and any others.
Write your own OAuth2 Auth Server
Write your own OAuth2 Resource Server
Over the next pages are some excerpts from there
69. 69
Java Spring OAuth2 “Client”
1. Include the OAuth2 Dependency
2. Annotate your app with @EnableOAuth2Sso
- This will automatically call the right endpoints and follow the client
side of OAuth2 Protocol
3. Configuration
1. OAuth2 : Client ID + Secret
2. Access Token URL: of Auth Provider
3. User Authorization URL: How AuthProvider will ask consent
AND YOU ARE ALL SET! MAGIC!
STANDARDS MAKE LIFE SO MUCH EASIER!
70. 70
Java Spring OAuth2 “Auth Server"
1. Include the OAuth2 Dependency
2. Annotate your app with @EnableAuthorizationServer
- Annotation implements the bunch of endpoints for you
3. Configuration
1. Allowed OAuth2 Clients : Client ID + Secret
2. Scopes supported :
71. 71
Java Spring OAuth2 “Resource Server"
1. Include the OAuth2 Dependency
2. Annotate your app with @EnableResourceServer
- Protects “/me” using the access token.
- authorizeRequests() will check the token validity