The document discusses OAuth 2.0 and its updates. It provides a brief history of OAuth including versions 1.0 and 2.0. It explains the core specification of OAuth 2.0 including authorization servers, resource owners, clients, access tokens, and response types. It also summarizes the token type specification and security considerations for OAuth implementations.
This document summarizes differences between Sign in with Apple (SIWA) and OpenID Connect (OIDC) and OAuth 2.0 standards. It notes several ways SIWA specifications and behaviors deviate from or violate OIDC standards, including not supporting standard authentication methods, response types, and claims. It also describes SIWA's characteristic identifier design which links multiple apps and services from the same developer together under a single user consent. Developer teams are limited to 10 linked apps/services and must create a new team for additional apps.
1. The document discusses OAuth 2.0 and OpenID Connect for API access control and authorization. It provides a brief history of OAuth and describes the core specification and response types.
2. The core specification defines two response types - code and token. The code response type uses authorization codes to obtain access tokens in a two-step process, while the token response type returns access tokens directly.
3. The document also covers token types, notably the bearer token which transmits no signature or secret and is commonly used for API access. It notes that some providers may not follow the latest OAuth draft specifications strictly.
The document discusses OAuth and OpenID Connect protocols. It provides diagrams illustrating the flows of OAuth authorization code grant, implicit grant and hybrid grant flows. It also compares OAuth and OpenID Connect, noting that OpenID Connect builds upon OAuth by adding an identity layer. Key aspects of OpenID Connect like ID tokens and their claims are outlined. Examples of OAuth and OpenID Connect implementations are provided at the end.
The document is a presentation on OpenID Connect 101 by Nov Matake of OpenID Foundation Japan. It provides an overview of OpenID Connect, including how it uses OAuth 2.0 with an added identity layer, the code flow process, ID tokens and their contents, scopes, discovery, and dynamic client registration. It also discusses password leaks, two-factor authentication, and security best practices.
Mit 2014 introduction to open id connect and o-auth 2Justin Richer
The document provides an overview of OAuth 2.0 and OpenID Connect (OIDC) protocols. It discusses how OAuth limits information sharing between parties in a protocol to improve security. It presents a diagram showing the separation of username, codes, tokens, sessions, and other credentials between the user agent, authorization server, client, and protected resource in the OAuth authorization code flow. The document emphasizes that OAuth and OIDC aim to avoid password proliferation, enable authentication and authorization across different systems, and provide a standardized user identity API.
This document summarizes differences between Sign in with Apple (SIWA) and OpenID Connect (OIDC) and OAuth 2.0 standards. It notes several ways SIWA specifications and behaviors deviate from or violate OIDC standards, including not supporting standard authentication methods, response types, and claims. It also describes SIWA's characteristic identifier design which links multiple apps and services from the same developer together under a single user consent. Developer teams are limited to 10 linked apps/services and must create a new team for additional apps.
1. The document discusses OAuth 2.0 and OpenID Connect for API access control and authorization. It provides a brief history of OAuth and describes the core specification and response types.
2. The core specification defines two response types - code and token. The code response type uses authorization codes to obtain access tokens in a two-step process, while the token response type returns access tokens directly.
3. The document also covers token types, notably the bearer token which transmits no signature or secret and is commonly used for API access. It notes that some providers may not follow the latest OAuth draft specifications strictly.
The document discusses OAuth and OpenID Connect protocols. It provides diagrams illustrating the flows of OAuth authorization code grant, implicit grant and hybrid grant flows. It also compares OAuth and OpenID Connect, noting that OpenID Connect builds upon OAuth by adding an identity layer. Key aspects of OpenID Connect like ID tokens and their claims are outlined. Examples of OAuth and OpenID Connect implementations are provided at the end.
The document is a presentation on OpenID Connect 101 by Nov Matake of OpenID Foundation Japan. It provides an overview of OpenID Connect, including how it uses OAuth 2.0 with an added identity layer, the code flow process, ID tokens and their contents, scopes, discovery, and dynamic client registration. It also discusses password leaks, two-factor authentication, and security best practices.
Mit 2014 introduction to open id connect and o-auth 2Justin Richer
The document provides an overview of OAuth 2.0 and OpenID Connect (OIDC) protocols. It discusses how OAuth limits information sharing between parties in a protocol to improve security. It presents a diagram showing the separation of username, codes, tokens, sessions, and other credentials between the user agent, authorization server, client, and protected resource in the OAuth authorization code flow. The document emphasizes that OAuth and OIDC aim to avoid password proliferation, enable authentication and authorization across different systems, and provide a standardized user identity API.
How do SAML, OpenID Connect and OAuth compare? How are they similar? Different? When do you use one or the other? For more info, also see my blog: http://gluu.co/oauth-saml-openid
Explains the process described in the core specification for OpenID Connect 1.0 which is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
This document summarizes Microsoft Azure Active Directory's support for OpenID Connect. Key points include:
- Azure AD can function as an identity provider supporting protocols like SAML, WS-Federation, and OpenID Connect.
- It also functions as an authorization server, allowing applications to register as protected resources.
- OpenID Connect support in Azure AD allows using the authorization code flow and retrieving tokens to call APIs on behalf of signed-in users.
- The document provides an example workflow using OWIN middleware and notifications in an ASP.NET MVC application.
The document describes the FIDO2 specification which includes WebAuthn and CTAP. WebAuthn introduces a new JavaScript API for browser-based authentication and CTAP introduces a new API for platform-based authentication. It provides an overview of the registration and authentication flows including the use of public key credentials on servers to authenticate users. It also describes extensions, attestations, credential management and the goals of convenience and strong security in the FIDO standards.
Suresh Attanayake is a senior software engineer at WSO2 who will present on enterprise single sign-on technologies including SAML, OpenID Connect, and WS-Trust. WSO2 is an open source software company that provides an integration platform. The presentation will cover common SSO standards and protocols, how they work, and factors to consider when selecting a technology for a given environment.
This document discusses OpenID Connect aggregated and distributed claims. It defines normal claims as those directly asserted by the OpenID provider. Aggregated claims are asserted by another claims provider but returned by the OpenID provider. Distributed claims are also asserted by another provider but returned as references by the OpenID provider. The document provides examples of aggregated and distributed claims and notes that distributed claims may be better for sensitive information as they do not require the OpenID provider to directly handle claim values. It also presents a use case of multi-step OpenID Connect and suggests other potential use cases.
A tutorial on how the process of writing an application using a browser’s WebAuthn API, plus how to install a server, how to generate authentication challenges & responses, and how to integrate with related IAM infrastructure.
Code: https://github.com/fido-alliance/webauthn-demo
Live slides: http://slides.com/herrjemand/jan-2018-fido-seminar-webauthn-tutorial#/
The Client is not always right! How to secure OAuth authentication from your...Mike Schwartz
The OpenID Connect or OAuth frameworks can be used to achieve a range of security levels. Properly used, it mitigates many risks. However, OpenID Connect’s flexibility, combined with its shared ontogeny with OAuth 2.0, creates opportunities for error--developers may not use (or even know about ) certain features necessary to achieve the transaction integrity they desire. The good news is that client software and middleware services can do some of the heavy lifting. You can have the best of both worlds--maximizing security and developer joy. Whether you’re a developer or security architect, what should you look for in an application that acts as an OpenID Connect client?
http://www.springio.net/stateless-authentication-for-microservices/
This talk is about how to secure your front-end + backend applications using a RESTful approach. As opposed to traditional and monolithic server-side applications (where the HTTP session is used), when your front-end 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 and JWT to achieve a stateless, token-based authentication and authorization using Spring Security in Grails. More specifically, the demonstration will be made using Spring Security REST, a popular Grails plugin written by Álvaro.
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.
The document discusses selecting authenticators for FIDO2 registration. It provides an overview of the FIDO2 registration process and the steps involved. It describes using the Authenticator Attestation Identifier (AAGUID) to identify the authenticator model and obtaining additional metadata from the FIDO Metadata Service (MDS). The MDS can provide details about authenticators, including how user verification and key protection are implemented. Selecting authenticators allows relying parties to control which devices can be used for authentication.
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.
The document discusses the W3C Web Authentication standard (also known as FIDO 2.0) for passwordless strong authentication on the web. It provides an overview of the key components and actors in the standard like FIDO authenticators, user agents, relying parties. It then summarizes the basic flows of registration and authentication in 2 phases. During registration, a key pair is generated on the authenticator and the public key is registered with the FIDO server. During authentication, the authenticator performs local authentication using the registered key and sends an assertion to the server for remote authentication.
Websites and applications are implementing social single sign-on to allow users to login using trusted authentication providers such as Google, Facebook, and even Salesforce. Join us to learn how to configure the OpenID Connect authentication provider to allow users to authenticate at Google to access a Salesforce environment. We'll also look at how you can relieve yourself of the burden of password management by having your web app login users via Salesforce.
OpenID Connect - An Emperor or Just New Cloths?Oliver Pfaff
OpenID Connect is a specification that defines an identity layer on top of the OAuth 2.0 authorization framework. It allows clients to verify user identity and obtain basic profile information about the user. OpenID Connect supports common identity use cases like single sign-on and identity federation through the use of ID tokens and user info endpoints. While it is not a complete replacement for SAML, OpenID Connect provides a simpler approach that is better suited for mobile and REST-based applications compared to the XML-based SAML standard.
OAuth 2.0 is an open standard for authorization that allows third-party applications to obtain limited access to a user's data without requiring them to share their passwords. It allows users to securely authorize third-party access to their private resources like photos, videos, contact lists, and calendars without sharing their passwords. The latest OAuth 2.0 specification was published in October 2021 and defines authorization flows and token types for confidential and public clients.
This document provides an introduction to Security Assertion Markup Language (SAML) 2.0, including:
- SAML is an XML-based standard for exchanging authentication and authorization data between parties like an identity provider and service provider.
- It defines roles like identity providers, service providers, and users.
- SAML supports single sign-on, attribute sharing, identity federation, and other use cases through protocols, bindings, and profiles.
- Liferay supports acting as an identity provider or service provider using SAML through an enterprise edition plugin, allowing configuration as an IdP or SP through properties and metadata files.
- The presentation demonstrates SAML single sign-on flows and configurations using examples
CEOS WGISS 36 - Frascati, Italy - 2013.09.19
Single Sign On with OAuth and OpenID used for Kalideos project and to be used within the French Land Surface Thematic Center
How do SAML, OpenID Connect and OAuth compare? How are they similar? Different? When do you use one or the other? For more info, also see my blog: http://gluu.co/oauth-saml-openid
Explains the process described in the core specification for OpenID Connect 1.0 which is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
This document summarizes Microsoft Azure Active Directory's support for OpenID Connect. Key points include:
- Azure AD can function as an identity provider supporting protocols like SAML, WS-Federation, and OpenID Connect.
- It also functions as an authorization server, allowing applications to register as protected resources.
- OpenID Connect support in Azure AD allows using the authorization code flow and retrieving tokens to call APIs on behalf of signed-in users.
- The document provides an example workflow using OWIN middleware and notifications in an ASP.NET MVC application.
The document describes the FIDO2 specification which includes WebAuthn and CTAP. WebAuthn introduces a new JavaScript API for browser-based authentication and CTAP introduces a new API for platform-based authentication. It provides an overview of the registration and authentication flows including the use of public key credentials on servers to authenticate users. It also describes extensions, attestations, credential management and the goals of convenience and strong security in the FIDO standards.
Suresh Attanayake is a senior software engineer at WSO2 who will present on enterprise single sign-on technologies including SAML, OpenID Connect, and WS-Trust. WSO2 is an open source software company that provides an integration platform. The presentation will cover common SSO standards and protocols, how they work, and factors to consider when selecting a technology for a given environment.
This document discusses OpenID Connect aggregated and distributed claims. It defines normal claims as those directly asserted by the OpenID provider. Aggregated claims are asserted by another claims provider but returned by the OpenID provider. Distributed claims are also asserted by another provider but returned as references by the OpenID provider. The document provides examples of aggregated and distributed claims and notes that distributed claims may be better for sensitive information as they do not require the OpenID provider to directly handle claim values. It also presents a use case of multi-step OpenID Connect and suggests other potential use cases.
A tutorial on how the process of writing an application using a browser’s WebAuthn API, plus how to install a server, how to generate authentication challenges & responses, and how to integrate with related IAM infrastructure.
Code: https://github.com/fido-alliance/webauthn-demo
Live slides: http://slides.com/herrjemand/jan-2018-fido-seminar-webauthn-tutorial#/
The Client is not always right! How to secure OAuth authentication from your...Mike Schwartz
The OpenID Connect or OAuth frameworks can be used to achieve a range of security levels. Properly used, it mitigates many risks. However, OpenID Connect’s flexibility, combined with its shared ontogeny with OAuth 2.0, creates opportunities for error--developers may not use (or even know about ) certain features necessary to achieve the transaction integrity they desire. The good news is that client software and middleware services can do some of the heavy lifting. You can have the best of both worlds--maximizing security and developer joy. Whether you’re a developer or security architect, what should you look for in an application that acts as an OpenID Connect client?
http://www.springio.net/stateless-authentication-for-microservices/
This talk is about how to secure your front-end + backend applications using a RESTful approach. As opposed to traditional and monolithic server-side applications (where the HTTP session is used), when your front-end 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 and JWT to achieve a stateless, token-based authentication and authorization using Spring Security in Grails. More specifically, the demonstration will be made using Spring Security REST, a popular Grails plugin written by Álvaro.
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.
The document discusses selecting authenticators for FIDO2 registration. It provides an overview of the FIDO2 registration process and the steps involved. It describes using the Authenticator Attestation Identifier (AAGUID) to identify the authenticator model and obtaining additional metadata from the FIDO Metadata Service (MDS). The MDS can provide details about authenticators, including how user verification and key protection are implemented. Selecting authenticators allows relying parties to control which devices can be used for authentication.
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.
The document discusses the W3C Web Authentication standard (also known as FIDO 2.0) for passwordless strong authentication on the web. It provides an overview of the key components and actors in the standard like FIDO authenticators, user agents, relying parties. It then summarizes the basic flows of registration and authentication in 2 phases. During registration, a key pair is generated on the authenticator and the public key is registered with the FIDO server. During authentication, the authenticator performs local authentication using the registered key and sends an assertion to the server for remote authentication.
Websites and applications are implementing social single sign-on to allow users to login using trusted authentication providers such as Google, Facebook, and even Salesforce. Join us to learn how to configure the OpenID Connect authentication provider to allow users to authenticate at Google to access a Salesforce environment. We'll also look at how you can relieve yourself of the burden of password management by having your web app login users via Salesforce.
OpenID Connect - An Emperor or Just New Cloths?Oliver Pfaff
OpenID Connect is a specification that defines an identity layer on top of the OAuth 2.0 authorization framework. It allows clients to verify user identity and obtain basic profile information about the user. OpenID Connect supports common identity use cases like single sign-on and identity federation through the use of ID tokens and user info endpoints. While it is not a complete replacement for SAML, OpenID Connect provides a simpler approach that is better suited for mobile and REST-based applications compared to the XML-based SAML standard.
OAuth 2.0 is an open standard for authorization that allows third-party applications to obtain limited access to a user's data without requiring them to share their passwords. It allows users to securely authorize third-party access to their private resources like photos, videos, contact lists, and calendars without sharing their passwords. The latest OAuth 2.0 specification was published in October 2021 and defines authorization flows and token types for confidential and public clients.
This document provides an introduction to Security Assertion Markup Language (SAML) 2.0, including:
- SAML is an XML-based standard for exchanging authentication and authorization data between parties like an identity provider and service provider.
- It defines roles like identity providers, service providers, and users.
- SAML supports single sign-on, attribute sharing, identity federation, and other use cases through protocols, bindings, and profiles.
- Liferay supports acting as an identity provider or service provider using SAML through an enterprise edition plugin, allowing configuration as an IdP or SP through properties and metadata files.
- The presentation demonstrates SAML single sign-on flows and configurations using examples
CEOS WGISS 36 - Frascati, Italy - 2013.09.19
Single Sign On with OAuth and OpenID used for Kalideos project and to be used within the French Land Surface Thematic Center
「信頼フレームワーク最新動向」~Open Government, Open Economy, Open Identity~
2011年7月28日(木)
http://www.openid.or.jp/modules/news/details.php?bid=41
http://www.ustream.tv/recorded/16287210
「信頼フレームワーク最新動向」~Open Government, Open Economy, Open Identity~
2011年7月28日(木)
http://www.openid.or.jp/modules/news/details.php?bid=41
http://www.ustream.tv/recorded/16287210
Open id specifications_work_update-tokyo_2011Nat Sakimura
The document summarizes an OpenID Specifications Update meeting that took place in Tokyo on May 20, 2011. It discusses efforts to update OpenID specifications to make authentication and user information sharing easier, especially on mobile devices. Key points include building on OAuth 2.0 and using JSON formats. After 31⁄2 years of work, consensus has been reached on new OpenID Connect specifications. Next steps involve finalizing specs based on developer feedback and implementing interoperable solutions.
The document discusses OAuth 2.0 and OpenID Connect. It provides an overview of OAuth 2.0's authorization code and implicit grant flows for obtaining an access token to access a secured resource. It also mentions OAuth 2.0 is used for access control in APIs and enterprises. Additionally, it states OpenID Connect is based on and extends OAuth 2.0 to provide identity features. Finally, it suggests these protocols are important for applications, access control, identity, social media, clouds, and the growing API economy.
This document discusses OAuth 2.0 and OpenID Connect for accessing APIs. It provides an overview of how OAuth 2.0 allows clients to obtain access tokens to access protected resources from an authorization server, including the steps to obtain an authorization code and exchange it for an access token. It then introduces OpenID Connect as an identity layer on top of OAuth 2.0 that provides authentication as well as authorization and allows clients to verify the identity of the resource owner. The document promotes OpenID Connect as an improvement over traditional OpenID that supports API access and a better user experience.
Creating a Sign On with Open id connectDerek Binkley
The document discusses OpenID Connect, which is a standard for identity authentication built on OAuth 2.0. It describes the basic steps in OpenID Connect including the client requesting authentication, the authorization server authenticating the user and obtaining consent, returning an authorization code to the client, the client exchanging the code for an ID token and access token, and validating the ID token. It also addresses challenges with maintaining session state across a distributed architecture and strategies for addressing those challenges like embedding an iframe to check login status with the authorization server.
OAuth 2.0 (RFC 6749/50) is a delegated authorization framework that makes requesting access for and authenticating as a client to an API as easy as getting a token and using a token. This session will explore the different OAuth flows in the spec as will as discuss extensions such as the JWT assertion flow and SAML bearer extension, and will also discuss security mitigations needed to use the protocol safely.
This document discusses authentication strategies for native mobile applications. It recommends using OAuth 2.0 with an authorization code grant to obtain access tokens securely without embedding credentials in the app. The key steps are: 1) opening a browser to request authorization; 2) handling the callback to exchange the authorization code for an access token; and 3) using the token to access APIs securely on behalf of the user. Authentication can leverage single sign-on or stored user identities.
This presentation describes best practices and considerations when using OAuth2 with native applications, and how best practices can be implemented with node in Electron and NW.js.
This document discusses token based authentication in ASP.NET Web API 2 projects. It covers the basic concepts of token authentication including the roles in OAuth 2.0 of resource owners, clients, authorization servers and resource servers. It also summarizes the different OAuth 2.0 client types, authorization grant types, and development options for implementing token authentication using OWIN middleware or DotNetOpenAuth.
My talk for the Dutch PHP Conference, explaining the point of oauth, the mechanics of oauth2 and the various flows, and a spot of oauth1 for completeness
CIS14: Consolidating Authorization for API and Web SSO using OpenID ConnectCloudIDSummit
John Bradley, Ping Identity
Overview of the different participant rolls in OpenID Connect, how JSON Web Tokens (JWT) are used, how OpenID Connect provides both authentication and authorization tokens in a single flow, and how OpenID Connect can support Single Sign on for Native Applications.
The document provides an introduction to API security with OAUTH 2.0, describing the basics of authentication and authorization, the four primary grant types including the authorization code grant process and actors. It also discusses criticisms of OAUTH including a lack of interoperability and being designed for hosted applications in 2006. Alternative security approaches like Oz are presented that build on the lessons learned from OAUTH.
This document discusses implementing a lightweight zero-trust network using the open source tools Keycloak and NGINX. It begins by explaining the transition from a traditional network security model with clear boundaries between public and private networks to a zero-trust model where security boundaries are defined individually for each service or pod. It then covers how to implement the underlying technologies of JWT validation, mutual TLS authentication, and OAuth MTLS using Keycloak as an authorization server and NGINX as an API gateway. Additional topics discussed include how to secure east-west internal traffic and resolve potential policy decision point chokepoints.
OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or...Brian Campbell
This document provides an overview of OAuth 2.0 and how it can be used to securely authorize access to APIs from mobile applications. It begins with an introduction to OAuth and discusses how it addresses issues with directly sharing passwords between applications. The document then outlines the basic OAuth flow, including key concepts like access tokens, authorization codes, and refresh tokens. It provides code snippets demonstrating an example OAuth flow for both Android and iOS, showing the HTTP requests and responses at each step.
Web authentication and authorization has come a long way in the last ten years. In this talk we'll look at where we've come from and how to OAuth and OIDC solved the problems we faced.
Takashi Norimatsu from Hitachi presented on sender constraint tokens as an alternative to holder-of-key bound tokens from the perspective of an implementer of Financial-grade API security profiles. Holder-of-key bound tokens prevent improper access by requiring proof of possession of the private key corresponding to the public key bound to the token. Sender constraint tokens similarly restrict access to only the specified token sender. The presentation discussed how authorization codes, refresh tokens, and access tokens could realize sender constraints using techniques like PKCE, client binding, and holder-of-key binding.
Oauth Nightmares Abstract OAuth Nightmares Nino Ho
https://www.hackmiami.com/hmc5-speakers-day-2
OAuth is one of the most popular authorization frameworks in use today. All major platforms such as Google, Facebook, Box etc support it and you are probably thinking of implementi ng OAuth for your product/platform.We are not debating the popularity of the protocol or the limitations that come with it. We are here to help you implement it securely. When you use OAuth, there are three pieces - The Platform , the Application (using the platform) and the User (of the application). We will go over the common flaws we have seen in applications built on a OAuth platform which can lead to complete account takeover, how they can be a security engineer's nightmare, and how to fix them. We will go over security controls that the platform can put in place to help mitigate security vulnerabilities. We will also cover how bad design decisions, if chained with otherwise lower risk vulnerabilities can result in gaping holes in your OAuth implementation. You will leave this session with a deep understanding of how OAuth implementation should be secured both for a platform and in an application and things to test for during a security evaluation of OAuth implementations.
Strong Authentication in Web Application #SCS IIISylvain Maret
Swiss Cyber Storm 3 Security Conference / OWASP Track
Strong Authentication: State of the Art 2011
Risk Based Authentication
Biometry - Match on Card
OTP for Smartphones
OTP SMS
PKI
SuisseID
Mobile-OTP
OATH (HOTP, TOTP, OCRA)
Open Source approach
How to integrate Strong Authentication in Web Application?
OpenID, SAML, Identity Federation for Strong Authentication
API, SDK, Agents, Web Services, Modules
PAM, Radius, JAAS
Reverse Proxy (WAF) and WebSSO
PKI / SSL client authentication
PHP example with Multi-OTP PHP class
AppSec (Threat Modeling - OWASP)
How to Build an Indivo X Personal Health AppBen Adida
Indivo X allows developers to build personal health apps that integrate with Indivo health records. The four key steps to building an app are: 1) defining the app's scope and functionality, 2) implementing authentication and authorization via OAuth, 3) making REST API calls to read and write data, and 4) using provided UI widgets for features like auto-complete and sharing/audit controls. The process aims to make app development simple while enabling access to rich health record data.
#idcon vol.29 - #fidcon WebAuthn, Next StageNov Matake
Nov Matake gave a keynote presentation at FIDCon about the next stage of WebAuthn and Passkeys on Apple platforms. He demonstrated syncing Passkeys across devices and using them for autofill on websites. Some challenges remain around credential changes and re-authentication. Syncing Passkeys across different operating systems like Windows, Android, and ChromeOS will also need to be addressed to make the experience better for users.
The document discusses authentication for browser-based and native apps using app-specific, IDP, and third-party backend APIs. It asks questions about obtaining and storing tokens for each API and passing tokens. Answers recommend using OAuth 2.0 for tokens, storing them in keychain/backend server, and passing as bearer tokens. Best practices are proposed like using a mediator flow and letting IDPs handle user interactions.
This document discusses LINE Corporation's LINE FIDO authentication solution and compares FIDO U2F, FIDO2, and FIDO UAF standards. It outlines the key components of each standard including message formats, protocol specifications, assertion data, and how they ensure interoperability across authenticators. It also mentions potential applications of LINE FIDO in areas like finance and IoT, as well as features like enrollment to address device loss.
This document discusses the OPTiM Store, which uses SCIM and OpenID Connect (OIDC) for provisioning and federation between systems like Active Directory and SaaS applications. It outlines the processes for tenant contracting, client registration, and credential exchange to enable synchronization of user identities and attributes from a SaaS application to the OPTiM Store using SCIM, and authentication from the store to SaaS using OIDC single sign-on.
The document discusses standards for identity federation and assertions. It defines four levels of federation assurance (FAL) based on the type of assertion used and how it is presented. FAL1 uses front-channel or back-channel bearer assertions signed by the identity provider. FAL2 adds encryption of assertions to the relying party. FAL3 encrypts assertions to the relying party for both front and back-channel. FAL4 uses holder-of-key assertions, where the assertion contains a public key and proof of possession, signed and encrypted to the relying party. The document provides definitions and discusses security considerations for federation and assertions.
SP 800-63-3 is an update to NIST's digital identity guidelines. It introduces a new framework that separates assurance levels into three components: Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL). This provides more flexibility and granularity over the previous version's single Level of Assurance (LOA). The document outlines the recommended requirements and mappings between the new IAL, AAL, FAL framework and the legacy LOA model from SP 800-63-2.
This document contains information about Nov Matake, including that he is a security engineer at GREE Inc. and evangelist for the OpenID Foundation. It discusses concepts related to digital identity including entity, identity, authentication, authorization, access control, and identity proofing. It also compares identity providers and relying parties in the context of single sign-on using services like Facebook and Disqus.
The document discusses the FIDO Alliance and its specifications for passwordless and two-factor authentication. It describes the FIDO Alliance's role in defining specifications, issuing vendor codes, and operating a certification program called FIDO Ready. The specifications cover areas like registration, authentication, and key generation in interactions between users' devices, authenticators, clients, and relying parties.
The document provides an overview of the MIT Kerberos & Internet Trust Consortium (MIT-KIT). It discusses the history and success of Kerberos authentication. The mission of MIT-KIT has expanded to address broader issues in identity, authorization, and privacy on the internet. It envisions an emerging personal data ecosystem where individuals control their own data. MIT-KIT is working on various open source components and standards to help realize this vision, including projects around OpenPDS and implementing the NSTIC Identity Ecosystem Steering Group framework.
This document discusses a self-issued open ID provider that allows identity in devices without central identity provider servers. It generates ID tokens on the device using a self-signed key pair stored securely on the device. The subject ("sub") claim in the ID token is calculated from the public key. This allows each device to have a unique ID token tied to the key pair, with no need for client registration or API access tokens.
The document summarizes several talks from the IIW #16 conference on identity topics. One talk discussed enabling single sign-on across mobile apps by storing an ID token in a shared keychain. Another discussed passing an ID token from a native mobile app to a browser to skip separate login. A third talked presented Google's vision for authentication over the next 5 years, focusing on setup instead of separate sign-ins, reducing bearer tokens, incorporating smarter hardware, and advanced combination authentication techniques. The last summary discussed using OAuth 2.0 and JSON Web Encryption standards for accessing patient health records through a Blue Button API.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
AI 101: An Introduction to the Basics and Impact of Artificial IntelligenceIndexBug
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
Project Management Semester Long Project - Acuityjpupo2018
Acuity is an innovative learning app designed to transform the way you engage with knowledge. Powered by AI technology, Acuity takes complex topics and distills them into concise, interactive summaries that are easy to read & understand. Whether you're exploring the depths of quantum mechanics or seeking insight into historical events, Acuity provides the key information you need without the burden of lengthy texts.
Ivanti’s Patch Tuesday breakdown goes beyond patching your applications and brings you the intelligence and guidance needed to prioritize where to focus your attention first. Catch early analysis on our Ivanti blog, then join industry expert Chris Goettl for the Patch Tuesday Webinar Event. There we’ll do a deep dive into each of the bulletins and give guidance on the risks associated with the newly-identified vulnerabilities.
Webinar: Designing a schema for a Data WarehouseFederico Razzoli
Are you new to data warehouses (DWH)? Do you need to check whether your data warehouse follows the best practices for a good design? In both cases, this webinar is for you.
A data warehouse is a central relational database that contains all measurements about a business or an organisation. This data comes from a variety of heterogeneous data sources, which includes databases of any type that back the applications used by the company, data files exported by some applications, or APIs provided by internal or external services.
But designing a data warehouse correctly is a hard task, which requires gathering information about the business processes that need to be analysed in the first place. These processes must be translated into so-called star schemas, which means, denormalised databases where each table represents a dimension or facts.
We will discuss these topics:
- How to gather information about a business;
- Understanding dictionaries and how to identify business entities;
- Dimensions and facts;
- Setting a table granularity;
- Types of facts;
- Types of dimensions;
- Snowflakes and how to avoid them;
- Expanding existing dimensions and facts.
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
Skybuffer SAM4U tool for SAP license adoptionTatiana Kojar
Manage and optimize your license adoption and consumption with SAM4U, an SAP free customer software asset management tool.
SAM4U, an SAP complimentary software asset management tool for customers, delivers a detailed and well-structured overview of license inventory and usage with a user-friendly interface. We offer a hosted, cost-effective, and performance-optimized SAM4U setup in the Skybuffer Cloud environment. You retain ownership of the system and data, while we manage the ABAP 7.58 infrastructure, ensuring fixed Total Cost of Ownership (TCO) and exceptional services through the SAP Fiori interface.
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
GraphRAG for Life Science to increase LLM accuracyTomaz Bratanic
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on integration of Salesforce with Bonterra Impact Management.
Interested in deploying an integration with Salesforce for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
Digital Marketing Trends in 2024 | Guide for Staying AheadWask
https://www.wask.co/ebooks/digital-marketing-trends-in-2024
Feeling lost in the digital marketing whirlwind of 2024? Technology is changing, consumer habits are evolving, and staying ahead of the curve feels like a never-ending pursuit. This e-book is your compass. Dive into actionable insights to handle the complexities of modern marketing. From hyper-personalization to the power of user-generated content, learn how to build long-term relationships with your audience and unlock the secrets to success in the ever-shifting digital landscape.
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
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.
Building Production Ready Search Pipelines with Spark and MilvusZilliz
Spark is the widely used ETL tool for processing, indexing and ingesting data to serving stack for search. Milvus is the production-ready open-source vector database. In this talk we will show how to use Spark to process unstructured data to extract vector representations, and push the vectors to Milvus vector database for search serving.
36. Core response_type = token
Resource Owner Client Authorization Server
Initiate
client_id=...&
response_type=token&
redirect_uri=https://...
Require Approval
Approve
All clients MUST pre-register “redirect_uri”
Access Token
OpenID TechNight #7
37. Core Notes
For Servers
Do you support public clients?
Do you need iPhone/Android apps support?
Require full redirect URI registration
Narrower scopes / shorter lifetime for public clients
For Clients
Don’t include client secret in your mobile app
OpenID TechNight #7
38. Core Security Considerations
Don’t issue “client_secret” to public clients
“redirect_uri” verification is important especially for
public clients
Consider security policy per client type
Use “state” param against CSRF / code injection attack
etc.
OpenID TechNight #7
40. Attacker Client Authorization Server
Initiate
Require Approval
Approve
Allow attacker to login
Code
with attacker’s Twitter account
Code
Code
Code
Access Token
OpenID TechNight #7
41. Attacker Client Authorization Server
Store “state”
Initiate in Cookie etc.
Require Approval State
Approve
Code State
State
Code
Code State “state”
verification
failed!!
OpenID TechNight #7
42. Token Type Spec
Authorization
Server
Authorize
Client Access
Access
Token
Resource
Server
Resource
Owner
Client API
Access
OpenID TechNight #7
43. Token Token Type Spec
Bearer MAC
No signature Signature
No token secret Token secret
Mainstream Similar to OAuth 1.0
+ extensions
OpenID TechNight #7
48. Token Notes
For Servers
Access Token Response
Set “token_type” as “bearer”
Resource Request
Support both “OAuth” and “Bearer” auth header
Support both “oauth_token” and “access_token”
query/body params
OpenID TechNight #7
49. Token Notes
For Clients
Move from “OAuth” to “Bearer”
Move from “oauth_token” to “access_token”
Only for Facebook API developers
Access token response will be JSON
OpenID TechNight #7