We are currently looking at rolling out ADFS 3.0 (Server 2012 R2). I've searched high and low, but it doesn't seem possible to revoke access and/or refresh tokens that have been issued by ADFS 3.0. Has any one accomplished this?
I'm also inclined to place an API in front of ADFS to handle revocation and audit/logging, but it seems this may be a 'hacked' solution.
Some guidance would be much appreciated.
In general OAuth2 tokens cannot be revoked (ie there is no signout). The applicable mechanism just disables a refresh.... This is radically different from WS-Fed passive and SAML2 browser SSO.
Related
after trial and error it seems to me that Google OIDC does not support the code flow without supplying the client secret:
https://developers.google.com/identity/protocols/oauth2/native-app#exchange-authorization-code
According to the latest best practices for SPAs (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13), code flow + PKCE is the recommended way to handle authentication. Is anyone aware of any trick required to make Google's code flow accept the code_challenge rather than the client_secret? Perhaps a dummy secret?
As of August 2020 the best practices document cited is still in draft and being activly updated - head revision here: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/. Googles' OAuth2 implementation has not yet applied the "work in progress" recomendation of PKCE being applied to web applications. SPAs are still directed to use the implicit flow in Googles' online documentation: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow).
The standard for PKCE (https://www.rfc-editor.org/rfc/rfc7636) details that it was developed as a mitigation for authorisation code interception attacks found on mobile platforms and was originally recommended for implementation by native clients. Google's documentation for "Mobile and Desktop apps" does direct developers to use a PKCE Authorization Code flow. Clients using Google Android, iOS or windows store credential types with PKCE may omit the client_secret (see the note on the refresh token parameter table - and confirmed by Cristiano).
It is now recognised that PKCE eliminates the need for any public clients to store a client secret, and as such can be used to deprecate the implicit flow which always had the flaw of including returned access and identity tokens in a redirect URI. https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead.
The draft IETF document states in section 2.1.1 that this recognition is likely to become a published standard.
Hopefully Google will update its implementation to remove the requirement for a client_secret for a PKCE token request when the best practices becomes accepted. In the meantime it seems we have no choice but to continue writing SPAs using the implicit flow.
A good alternative IMHO consists in using Keycloak as IDP and then adding Google to the delegate identity providers of your Keycloak instance (and then Facebook and then any other idp if required). Keycloak implements the PKCE flow or whatever flow in the Oauth 2 RFCs in a reliable way. That means you need a hosted instance of Keycloak though.
Well, I'm using openId Connect authorization code with pkce without using client_secret in an android app using this lib: https://github.com/openid/AppAuth-Android.
I just had to ensure that the custom scheme was set using the app's package name from the manifest and use it to register the android credential on google console.
I'm new to OAuth 2.0 and OpenIDConnect
I want to ask if is it necessary to implement OAuth 2.0 and OpenIDConnect for our login, register flow of our own created client application (mobile apps and server side app)?
Because I've been searching tutorial to implement login, register flow the best practice right now is using OAuth 2.0 and OpenIDConnect but their implementation is toward to securing our API against other people client application. Is this auth flow is just used to secure another people client application to access our API?
Thank you
OAuth 2.0 is both elegantly simple or extremely complex depending on your understanding of the technology and how to implement authorization.
I'm new to OAuth 2.0 and OpenIDConnect I want to ask if is it
necessary to implement OAuth 2.0 and OpenIDConnect for our login,
register flow of our own created client application (mobile apps and
server side app)?
No, it is not necessary to implement. There are many methods of authentication and authorization. OAuth is just one of the more popular methods.
A simpler and terrible method is to just implement username and passwords for your users. Simpler, in this case, is a relative term as now you need to worry about keeping usernames and passwords stored somewhere securely.
OAuth can be used to secure public access to your website, applications (REST endpoints), and more. OAuth can be used for server to server authorization. In the end, OAuth is just a method of creating a token that is presented to a service. The service verifies the access rights of that token and denies or proceeds with the request.
Authorization and Authentication are domains that require a lot of experience to implement correctly. There are many nuances to consider. That is why so many companies are breached, they do it wrong or implement weak methods. At one company I visited for an audit, I wrote down 10 usernames and passwords because everyone had yellow postit notes on their monitors. Even the best OAuth implementation will have problems with that level of security.
I'm just starting to learn about Identity Server, OAuth 2, and OpenId Connect. While doing so I've spent some time looking over the different OAuth flows and their applications. I understand the risks of using the Resource Owner Password Credential flow when the client is 3rd party or not trusted. However, I haven't really been able to find much on its use when the client(mobile app) and api are trusted 1st party. What are the potential risks of using this flow in this scenario? If you could point to specific security vulnerabilities that would be very helpful.
Thanks!
If you are talking about exactly the following...
Your own Mobile App (using trusted libraries)
Collects User Credentials (as if they were logging on your website, assuming you have one)
Sends them over TLS to your Auth server
Returns the normal token response if correct
Then I would argue there is no security penalty, at least, it is no worse than using username/password auth in the first place.
However, there is a wider problem with mobile authentication of this nature.
There is no way to tell that it's your app sending the requests, this applies to all OAuth2 flows (even if you use a more secure flow, the User can simply pull apart the mobile app and extract the credentials).
There are some features from both Google and Apple that attempt to fix this problem, but I'm not sure how mature or secure they are at the moment, it might be worth looking into.
So you are relying on the User to not get tricked into installing a fake app, however, this lands under social engineering and it does apply to all OAuth 2 flows.
I am at a point in a project where I might be needed to bring to table concerns/reasons why OAuth (or even OpenID Connect) should be taken up as the way to go for any future Web and Native Apps over using SAML.
The documentation I have gone through makes the case for the simplicity of OAuth (to which I can attest) but doesn't say it cannot be done in SAML. I've worked with OAuth and I can attest to it's simlpicity but not with SAML that much, but still know that it can be done using SAML, but I think it's way more complicated in that case.
Can anyone point me to an authoritative source that can make that claim and produce any numbers/documentation in favor of OAuth ?
SAML and WS-Fed are enterprise protocols. They have complicated cryptography standards. In the most used profiles, they require browser functionality since the protocol is driven via browser redirects. The token used is a SAML token, XML based and can be large.
If you want to federate with SaaS applications e.g. Salesforce, Workday they only support SAML.
SAML and WS-Fed support SOAP and WCF, no web API.
OAuth is a light-weight protocol suitable for native devices (headless, desktop, WPF), mobile applications etc. There is no browser functionality here so SAML etc. cannot be used. Also these devices are not suitable for complex cryptography
OAuth has a range of profiles e.g. authorization code grant (where OpenID Connect comes into play) and client confidential (that depends on mutual knowledge of a secret key).
It supports web API only.
The token used is JWT - far less bandwidth.
The choice is by use case. One is not "better" than the other.
Refer the scenarios here - Authentication Scenarios for Azure AD.
Please tell me the difference between these third party authentications i.e open id, o-auth1.0, o-auth1.0a ,o-auth2.0 and open id connect.
Well i googled on this but not able to find the exact difference between all these. All the time I got difference between o-auth and open id but not about all these together.
Any reference or any explanation would be appreciated. Thanks in advance.
First of all, note the difference between authentication and authorization: not all the protocols in your question actually do authentication.
During authentication you prove your identity to someone else (e.g. show driving license), see OpenId.
During authorization you give access rights to someone else to use a protected resource (e.g. give car keys), probably without exposing your identity, see OAuth. OAuth 1.0 works, but a common complaint is that both server and client has to do a lot of cryptography, so it's not lightweight on the client side and does not support embedded clients (e.g. javascript). OAuth 1.0a addressed a security issue, but it's obsolete, the fix was included into the original spec (RFC 5849). OAuth 2.0 supports both remote web application and embedded/javascript clients and allows implementing a client application much easier.
OpenId Connect unites OpenId and OAuth (thus providing both authentication and authorization) as a small extension to the OAuth 2.0 protocol.