I am trying to implement an OAuth2 Authorization Server that supports the OAuth2 Device Profile. This is not in the final RFC, but was in drafts until 2010. You can find the draft here:
https://datatracker.ietf.org/doc/html/draft-recordon-oauth-v2-device-00
How can I leverage DotNetOpenAuth to accomplish this task? I am currently playing around with the AuthorizationServer sample, with little success.
DotNetOpenAuth hasn't claimed support for the device profile spec yet. While it may be possible for you to accomplish this using the library, it hasn't been done before to my knowledge. I suggest you file a request for this feature
Related
I read this article.
Gmail can't be use in third-party component without using OAuth 2.0?
Should a personal account also use the OAuth 2.0 when using a third-party library?
If you are using Gmail or any other Google API you should be using OAuth 2 flow to ensure a more security scenario.
For your actual questions, yes you need to use OAuth flow to authenticate to any Google API as required, the link you posted about Less Secure Apps already says that they will be deprecated anytime soon and are pretty much discouraged.
Background:
I want to integrate SSO in my existing application with my client's application and client IDP does not support any SAML and OAuth standards.
Problem Statement:
I'm looking for a custom solution where if any client application simply opens a link of my application then my application must be able to recognise that user/client and should auto logged-in into my application.
Though, I've done enormous research before asking this question in this forum:
My findings so far:
Some of my findings which I can use to auto login into my system using the following custom techniques:
JWT token
Certificate
Simple encryption using a secret key token. ie AES, RSA
Are there any other custom secure options available?
And what option one should choose in this kind of situation?
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.
I am building a chrome extension which will interact with salesforce-chatter api. But for a user using oAuth(User agent flow) authentication, I need to embed my client key in my extension.
Will this cause any security problem? Or is there a way to use oAuth without embedding client id in my extension?
The client id has to be included into a request, so the provider knows that the request came from you, as #Matt Lacey already pointed out. Normally, the provider also issues a confidential client secret that is additionally included into the access token request, so the provider can verify that your app is allowed to use that client id.
Chrome extensions run on an open platform and the platform itself provides no methods for either authenticating the extension against a server (which salesforce would then also have to support) or storing properties securely (would be hard, if not impossible on an open platform), so keeping the client secret confidential is unfortunately not possible.
As this is a common problem, it is already considered in the OAuth specification (see section 10.1 Client Authentication and 10.2 Client Impersonation). The provider is therefore required to do additional checks, but on the client side you can't do anything to effectively improve security.
If you want some more insight into how this will be handled on Android devices in the future, check out my answer here.
You have to embed the client ID in the extension to let Salesforce know what the app is that's trying to authenticate. These client IDs are intended to always be stored and passed to the server, so as long as you're storing it in a secure manner there shouldn't be a problem.
As Matt explained if you are creating a packaged app you will be forced to include the client id. Another solutions is to write the app as a hosted app:
What is the difference between packaged apps and hosted apps?
The drawback of this is the added complexity of managing a web server. But it will allow greater security.