I have a desktop client application that uses Azure AD to authenticate users.
I wish to use the same authentication already provided by the user in the client application and pass the token to a new Blazor project. So if i pass the refresh_token as a queryparameter to my new web application can i use it to genreate new access tokens for that user without the need for them to re authenticate?
No, you cannot use a refresh token on a SPA application and Blazor is a SPA. Because there isn't secured way to store the refresh token on a browser.
However, you can renew the access token. Actually the access token is automatically renewed using the same mechanism oidc.js use (by using an iframe).
You must configure your client with the authorization code flow with PKCE (or implicit flow, but it's deprecated)
Related
I am trying to figure out how to perform single sign on with OAUTH2 on two different applications. Currently according to my understanding I can use the Authentication Provider in order to authenticate my clients. The procedure is the following:
The client is redirected to the Authentication Provider
Then the client is loggedin and has the code
The client provides the code to my application
The server uses the code in order to retrieve the access token.
Using the access token my server uses the remote API to retrieve information
Now I have a second application in a different backend (PHP) that I want to inform that the user is already loged in via the OAUTH. My naive solution is to provide the access token of the first application to the second application in order to perform the authentication. However, I understand that I am not allowed to share the access tokens between apps.
Every backend service should validate the access token via introspection. The only introspection guarantees that the token is valid, not expired or revoked.
So you have to pass the access token to the Backend service. To secure that you can use HTTPS API.
You are correct regarding not sharing the access token. The Authentication Provider should also allow creating an ID token. You would configure your second application with the authentication provider and get a client id. Both the client id and ID token are required to sign in the second app which will generate it's access token.
What grant type are you using?
Both apps need to redirect the user:
In the first app the user will authenticate and the app will get an access token scoped to that app.
In the second app the user will be automatically signed in without needing to reauthenticate. The app will then get a separate access token, generally with different privileges to that of the first app.
This is standard SSO behaviour and it is best to accept it. Usability is pretty good. Trying to share tokens is not advised unless you have advanced requirements.
Background
I have a MVC 5 Web App and hosted in Azure App Service as Web App and secured with Azure AD; Anybody with valid AD credentials can authenticate themselves and view all HTML Content in the Web App;
Objective
I need to give just one of these MVC-View to outside individuals to view. For such we have already created an User in Azure AD which we will be sharing the details with the outside world. Hence, the thrid party will need to write some code to authenticate to our Azure AD and view this HTML content non interactively (Which means without allowing the third party app to prompt to enter user credentials from Azure AD).
What I have thought about
Assume that I am the third Party, I am going to authenticate to Azure AD from a Console/WinForms/HTML
Page and get myself a token; Then I will be using the token, to open
up a Browser to view this page.
Challenges I see
Session Expiration
Session Validity
Putting everything intto a Picture
Please show me some guidence to accomplish the objective.
Hence, the thrid party will need to write some code to authenticate to our Azure AD and view this HTML content non interactively (Which means without allowing the third party app to prompt to enter user credentials from Azure AD).
Per my understanding, you could leverage the OAuth 2.0 Client Credentials Grant Flow by using the client_id and client_secret.
Also, you could use OAuth 2 Resource Owner Password Credentials grant. Note: The resource owner password grant doesn't provide consent and doesn't support MFA either. Detailed tutorial, you could follow here.
Based on the authentication implementation part in your Web App, you could follow the approaches below to implement your scenario:
For using App Service Authentication / Authorization
You do not need to modify any code in your Web App project.
For using Microsoft.Owin.Security.OpenIdConnect middleware
You could use Microsoft.Owin.Security.ActiveDirectory package in your Web App for supporting AAD bearer token authentication, and this middleware need to be configured before the other authentication middlewares as follows:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = "{the-AAD-clientId}",
Tenant = "{TenantId}"
});
//app.UseCookieAuthentication
//app.UseOpenIdConnectAuthentication
For the client (the third Party), they could leverage the above two flows (Client Credentials Grant Flow ,Resource Owner Password Credentials Grant Flow) to retrieve the access token without user interaction. Then they could access the specific view page by using the token as follows:
Get https://{your-app-name}.azurewebsites.net/home/index
Header Authorization:Bearer {the-AAD-accessToken-or-IdToken}
For retrieving the token, you could follow this tutorial for using User Password Credential flow. For Client Credential, you could just construct the ClientCredential instance when invoking AcquireTokenAsync for getting the token.
Additionally, you could create a new AAD application for this scenario or just use the AAD application for your current Web App. Moreover, there may exists risks when exposing the username & password or clientId & ClientSecret to the third Party, I would recommend you expose a new endpoint for generating the token in your Web App backend and return the token to the third party for security consideration.
I am building an Angular SPA app and using Okta as an Idp. since its an SPA so I think I need to use Implicit flow. I have two queries here-
Since in Implicit flow a refresh token is not issued, does it means that th user will be logged out of the app after the token expires and he has to log in again?
Why do I need to use Implicit flow in case of SPA? why not Authorization code flow? since I have control over both the front end (SPA) and back end (REST API) . for example in case of Spring MVC architecture for the web app Authorization code flow is possible.
Thanks,
pchh
Yes, if the token expired, you have to re-autenticate. Normally you still have a valid session on the identity providers site, so you can do a "silent" login using an iframe. Libraries like oidc-client support a silent login, which can do this for you.
You need to use implicit (or hybrid) flow, when you need to access to the access token from your javascript app. With authorization code flow your javascript app doesn't get the access token, so if your API needs an access token for authorization, what are you going to send?
If your auth server supports OpenID Connect (OAuth2 extension) and single sign-on (SSO) feature, to get a new token before the old gets expired, use an iframe with a URL you used for authentication, but add prompt=none parameter (and possibly id_token_hint parameter). See OpenId Connect RFC. The prompt=none parameter tells the /auth endpoint to issue a new token(s) if the user has an open SSO session at your OAuth2 server. If not, the request will fail. There is a separate RFC for session management.
The Authorization code flow requires you to access the /token endpoint, which usually requires authentication (client ID + client secret) and you cannot keep the secret safe in a browser. For this reason, the token endpoint doesn't use to support CORS headers, so you cannot access it using XHR. Using the Auth code flow, you get a code as a redirect URL param (?code=), which gets to the server hosting your SPA (browser sends it there after redirect). The implicit flow returns tokens in hash part of the redirect URL (#access_token=), which stays in a browser (it's not sent to the server), so it's safer.
A quick overview of the problem.
I have a client application that will use IDS to authorise access to a google service on behalf of the end user.
However, the client application isn't, itself responsible for talking to google. There is a Server app that does some magic with the user's data on his behalf.
Now, if I understand things correctly, the server app will use the Access Token supplied by the client app to talk to google. What happens when that access token expires? As I understand it the client application is expected to use the refresh token to as for a new access token.
Is there an issue with the server using this refresh token to update the access token? What flow am I supposed to use to make this magic happen?
A server using a refresh token to get a new access token is a valid use case.
If you're working with OAuth you can use the Client Credentials or Resource Owner flows to use refresh tokens, otherwise for OpenID Connect you'll need to use Authorization Code or Hybrid.
I am trying to implement Oauth 2.0 provider. I am confused on access token grants. I am using oauth2orize module in node.js.
I am confused on Should I remove all access token related to specific user when user logouts from auth server? I am building mobile and single page app for browser and I am using Resource owner password credential flow. How long should access token be valid for and should it expire on logout?
Generally, an app will revoke an access token just prior to performing logout. Typically, the app will revoke a refresh token if it got one, as that will also invalidate any and all access tokens.
From the perspective of the authorization server, I would keep these things separate and implement both:
Revoke (RFC 7009)
Logout (OpenID Connect)
Then, the clients can use either / both of these as they need. If you have some constraints in your environment, you may be able to automatically revoke tokens during logout in your authorization server. Generally though, an it should allow for both to be used independently and put the client in control.