I want to build a clone of Sheetsu application using python. For this, I need to authenticate and authorize the user. I came across three types in OAuth 2.0 authentication flow. They are
1. Web server
2. Installed application
3. Service account
Can Someone explain me the difference between all the three?
OAuth2.0 Scenarios:
Web server
The Application which user interacts with is hosted on a web server. The user wants to delegate access to his data to this application
Suggested OAuth2.0 Flow:-
Authorisation Code Grant.
Installed application
Application which user interacts with is hosted on a device e.g. phone application or desktop application. Again, the user wants to delegate access to his data to this native application
Suggested OAuth2.0 Flow:-
Authorisation Code Grant with PKCE.
Service account
Application is hosted on a web server. The application requires a token to access data from an API, but not in the specific context of an end user
Suggested OAuth2.0 Flow:-
Client Credentials Grant.
Or, Resource Owner Password Credentials passing in a service account username and password - some legacy APIs work like this but avoid this flow when possible.
There is another type of app as well:
Single Page App (SPA)
The application which a user interacts with runs on their web browser server. The user wants to delegate access to his data to this application
Suggested OAuth2.0 Flow:-
Authorisation Code Grant with public client if available else,
Implicit Grant.
Related
My company's application has a website xyz.com, and the user authentication is done via Auth0 SSO. There is another service which we internally use, and Auth0 SSO is configured on that as well (hosted on service.xyz.com).
Now, this service also has a SDK (in form of JS) through which it allows us to embed its components. However, that requires me to get access to its accesstoken.
When I'm in context of our company' website (after logging into xyz.com), I can access the Auth0 token, but in order to make use of service provider's SDK and integrate that in our website, I would somehow need to get the appropriate oauth token for that service provider.
My question is, how is this usually done?
We're in a scenario where a single page application that we develop ourselves (AngularJS front end with https server APIs in the back) opens another
web application developed by a partner of ours in a new browser tab, and where this second web application needs access to a https server API that is also developed by us.
After looking around for possible solutions, we have now created a proof of concept using IdentityServer4, where the second web application is configured as a client with "authorization_code" grant type. When all applications are running on the same domain, the third party application is able to access our https server API without being prompted for user id and password.
The implementation of the second web application in this proof of concept is very much like the solution presented by bayardw for the post
Identity Server 4 Authorization Code Flow example
My question now is:
When - in production - the second web application no longer shares domain with our application and our https server API, will a call from the second web application be prompted for username and password when accessing our http server API?
Seems, you are missing some major things. First of all any API should never ask for username and password. Instead your app(s) should put a token into each request and API should validate that token. Where the user credentials should be asked is when a user accesses your (or 3-rd party) web application. Then Identity Provider creates an Identity token (usually to be persisted in a cookie and used within the app) and access token (to be provided to APIs). Each token is issued for specific Client (app) pre-registered in IdP. Probably when been hosted at the same domain your two apps shared the identity cookie and Client Id what is not correct. In production scenario you have to register the apps separately. All the rest should work fine (if you follow the routine i briefly described at the beginning).
Chosing to post an answer myself from feedback through other channels:
This boils down to the session tracking of the IdP. If cookies are being used to track IdP session, the behavior is impacted by whether a session cookie or a persistent cookie is used.
In general, I have found that Robert Broeckelmann has great articles on medium.com.
Our apis are being consumed by 3rd party deamon applications as well as client applications. For third party deamon application we can expose the api via the client credential oauth flow and for the client application(S) we use the implicit grant outh flow.
The challenge we are facing is that in case of the implicit grant flow the user details are fetched from the ACCESS TOKEN. But when the same api is used for the client credential flow the user details can not be fetched from the ACCESS token as it has only application specific details.
What is the the best api design approach to handle the above challenge ?
Do I need two set of api(s) one for integrating with client application and one for integrating with server application ?
Will the usage of any alternative oauth flow help ?
Refer to Authentication scenarios for Azure AD documentation, as you stated correctly user interaction is not possible with a daemon application, which requires the application to have its own identity. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
Hence, the recommended way is two have two version of api implemented with two different type of authentication based on your scenario.
Reference -
Daemon or server application to web API
Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
We want to code a web-application (with ASP.NET Core) that starts a legacy Windows desktop application via a custom URL protocol. The web-application must use an authorization server for obtaining an access (bearer) token via OAuth 2 with which it has access to the user's resources via an ASP.NET Core Web API. The desktop application must be able to access the user's resources via the Web API too. How can the desktop application obtain an access token?
I can think of the following options:
The desktop application shows a login screen, sends the entered username and password to the authorization server (using the “Resource Owner Password Credentials” grant type of OAuth 2) and gets an access token back.
The desktop application shows an embedded browser window. The embedded browser requests the OAuth Authorize endpoint of the authorization server (using the “Authorization Code” grant type of OAuth 2) and the user must log-in to authorize. The authorization server redirects back to the redirect URL. The desktop application intercepts this redirect, extracts the authorization token and uses it to get an access token.
The web-application starts the desktop application and passes its access (bearer) token as an argument to the desktop application.
Before starting the desktop application, the web-application requests a new authorization code from the authorization server. The web-application starts the desktop application and passes the authorization code as an argument to the desktop application. The desktop application exchanges the authorization code for an access token by sending the authorization code to the OAuth Token endpoint of the authorization server.
We do not wish to use the first and second option, because we want single sign on.
The third option does not seem to be a good idea, because malicious software on the user’s desktop PC can obtain and use the access token too.
The fourth option seems to be the only option left. As far as I know an authorization code is a temporary (short-lived) one-time token. Besides that, you need to know the client secret for obtaining an access token.
Can anyone confirm that option four is the way to go? Or did I overlook something?
Are there any examples with IdentityServer for this scenario?
Both application should share a logon session using the system browser. This way the user gets SSO in the native app (and even vice versa).
The spec describes the best practices for native apps:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-12
In your case there is a flow that is made specially for desktop application:
Client Device Flow for OpenID connect allows Application that do not have any "browser capability",this Flow will typically suit well Desktop applications.
I am trying a POC with WSO2 API manager and Identity server. The application users are registered to the user store on the identity server. An API is exposed on the API manager that will be used by the application. The goal is to authenticate the users accessing the application using the oauth resource owner password credentials. The user credentials are in the user store on the identity server.I created a new tenant for this.
I configured SSO for the API manager by using this documentation. so that the users are authenticated against the identity server user store.
Tried to generate a token to access the API exposed on the API manager. I was able to retrieve the token client credentials grant type but not for the resource owner password grant type.
Appreciate any help here.
I do not think, you need SSO here. SSO is needed with APIM and WSO2IS, if users need to login to the API store/publisher/APIM management console. I hope you are talking about end users.. Then end users are may not need to login to the APIM. They just need to login your custom applications and application would call the APIs in the APIM.
But, say user need to login to custom applications using SSO, then you can configure SSO between WSO2IS and custom applications. Please refer here. Once user login to the application, application can exchange a end user's SAML2 Assertion with access token by using APIM. Then application can access the APIs in APIM using access token behalf of the user. You can refer this for more details
Also, if you are just trying to use OAuth just for authentication, You may need to use openid-connect. (just to login to custom application)