In my mobile app, I have a singleton Ktor HttpClient with bearer authentication configured as such:
HttpClient(…) {
install(Auth) {
bearer {
sendWithoutRequest { requestBuilder -> some condition }
loadTokens(tokensStorage::getTokens)
refreshTokens {
performTokenRefresh(oldTokens.refreshToken)
}
}
}
}
Now consider the following flow:
The user opens the app while the tokens stored in my tokenStorage are not valid.
The HttpClient loads the tokens from tokenStorage and the request fails with a 401.
The HttpClient tries to perform a refresh but it fails too because the refresh token is invalid.
The user is redirected to the login page, logs in, and the new valid tokens are stored in tokenStorage.
Now from the app the user can retry the call that failed in points 2-3. However this will fail forever until the app is closed, because the HttpClient never tries to call loadTokens anymore. Indeed, as far as I can see from the source code, loadTokens is called only once and then never again.
I found out a couple of ways to solve the issue.
The first one is to manually retrieve BearerAuthProvider from the HttpClient and clear the token myself like in the following snippet, but it seems like a hacky workaround:
httpClient.plugin(Auth).providers
.filterIsInstance<BearerAuthProvider>()
.first().clearToken()
Another one is to manually load the current token from my tokenStorage in refreshToken and disregard what get passed in this#refreshTokens.oldTokens:
refreshTokens {
val currentRefreshToken = tokenStorage.getTokens().refreshToken
performTokenRefresh(currentRefreshToken)
}
However this means that the client will do an unnecessary call to the refresh API, while having already a valid token pair (obtained from the login).
So my question is: is there a cleaner way to handle the situation? Am I misusing Ktor?
Related
Exploring the ServiceStack authentication providers for the first time. Have gradually built up a test project by adding BasicAuthProvider and when that worked, added GithubAuthProvider. The last one added was JwtAuthProvider and that works as well. When I retested authentication with any of the previous authentication providers such as Github, for example, I find that the JwtAuthProvider lambda function for CreatePayloadFilter is still being invoked. This was not expected.
The AuthFeature plugin is as follows:
Plugins.Add(new AuthFeature(
() => new PartnerWebSession(),
new IAuthProvider[] {
new JwtAuthProvider(appSettings) { ... },
new BasicAuthProvider(), //Sign-in with HTTP Basic Auth
new GithubAuthProvider(appSettings)
}));
I have created BasicHello, GithubHello and JwtHello service models with different end points for use with each of the authentication providers with routes:
/basic/{Name}
/github/{Name}
/jwt/{Name}
The AuthenticateAttribute has been attached to the Service classes designed to work with these models and they each specify the Provider to use, e.g.:
[Authenticate(Provider = "basic")]
public class BasicAuthentication : Service
{
public object Any(BasicHello request)
{
return new BasicHelloResponse { Result = $"{nameof(BasicAuthentication)} says Hello, {request.Name}!" };
}
}
Testing using Visual Studio debug and Chrome browser. Have ensured that no previous cookies JWT are hanging around from previous tests by clearing cookies for all time. I enter the URL:
http://localhost:52070/api/github?name=stephen
This takes me to the ServiceStack rendered authentication screen with login dialogue and "Sign In with Github" button. Click the "Sign In with Github" button which takes me to the "Sign in to GitHub" page provided by GitHub. Successfully authenticate, and then code execution hits a breakpoint I've set in CreatePayloadFilter lambda of the JwtAuthProvider.
I did not expect this. Is this an error or am I doing something wrong?
If you have the JWT AuthProvider registered it populates the successful Auth Response with a populated JWT Token that encapsulates the partial authenticated session.
The stateless client JWT Token (i.e. instead of server session cookies) can then be used to make authenticated requests after a successful OAuth Sign In.
I'm lookig at MSAL and I'm trying to understand what's the correct way to use it in a client app. In my case, I'd like to authenticate the user and then use the id token against a "private" web api app.
Now, I was under the impression that AcquireTokenSilentAsync would reuse an existing token from the cache (when available) without performing an extra call to the authentication endpoint if the token was still valid and the requestes scopes could be satisfied (this was my interpretation and it probably is wrong). However, this seems not to be the case. What I'm seeing with fiddler is that this method will always access the authorization endpoint.
Initially, I thought that my client service wrappers should always cal this method in order to get the id token, which would then be passed to the backend web site through the authentication bearer header. Here's an example of what I mean:
public async Task<string> GetAllWorkers() {
_httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", await GetToken());
var request = new HttpRequestMessage(HttpMethod.Get, _url);
var resposta = await _httpClient.SendAsync(request);
var content = await resposta.Content.ReadAsStringAsync();
return content;
}
GetToken is a method that wraps the typical code used for authenticating the user (uses a try/catch block for wrapping the AcquireTokenSilentAsync and, when that fails, redirects the user to the AcquireTokenAsync method for showing the login UI).
The question: is having this extra call before all my backend services really the way to go? Or should I cache the token and reuse it in all the internal web services call until I get a 401 (and only then should I call the GetToken method to refresh my id token?)
Editing to give more info
_clientApp = new PublicClientApplication(ClientId,
Authority,
TokenCacheHelper.GetUserCache());
TokenCacheHelper is the token cache helper that comes with most Azure AD samples. The GetToken method which returns the authentication header is a single liner that interacts with the helper that encapsulates the _clientApp field shown above:
return (await _helper.AuthenticateUser()).IdToken
And here is the AuthenticateUser method:
public async Task<AuthenticationResult> AuthenticateUser() {
try {
return await _clientApp.AcquireTokenSilentAsync(_scopes, _clientApp.Users.FirstOrDefault());
}
catch (MsalUiRequiredException ex) {
return await RetryWithGraphicalUI();
}
}
Now, the token cache helper is being hit. What I don't understand is why the AcquireTokenSilentAsync method ends up always calling the oauth2 endpoint (https://login.microsoftonline.com/{azure ad guid}/oauth2/v2.0/token)...
Meanwhile, I've changed the code making my helper class cache the AuthenticationResult. Now, AcquireTokenSilentAsync will only be called when one of the "internal" app's web api methods return 401 in response to a call performed with the bearer authorization header.
In the end, I've went along with caching the AuthenticationResult and it's ID Token. This seems to be the best option since it saves me a remote call. I'll only try to call AcquireTokenSilentAsync again when the web service returns 401.
I have an ember application that uses the Auth0 Ember Simple Auth addon to use the Ember-Simple-Auth functionality with Auth0's Lock.js. Recently I have been trying to implement single-sign-onfunctionality, such that if a user logs into a login portal application, their session will be preserved for other applications on the same domain, and they will not need to log in repeatedly. However my implementation of SSO is resulting in an infinite redirect loop between my login logic and Auth0's endpoint.
I have enabled SSO in the Auth0 application settings. My login is implemented in a few blocks.
My route.js contains a beforeModel() method which contains:
if (!get(session, 'isAuthenticated')){
// Forward to the login action
}
My login action:
login() {
var session = get(this, 'session');
session.authenticate('authenticator:myauthenticator', { authParams: { scope: 'openid' } });
}
This grabs the session object, and calls my custom authenticator. So far, this is basically just ember-simple-auth boilerplate, and complies with the examples supplied in the Auth0 Ember-Simple-Auth documentation.
Where I run into trouble is my custom authenticator. The base authenticator is here. You can see that it handles basic login logic easily, including showing the Auth0 lock when a user isn't authenticated. However it has no logic for handling the kind of SSO-session checking that I want to implement. So I implemented a custom authenticator as below, using examples provided by Auth0 for (basically) this exact scenario (you can see their examples [here], I'm using a slightly altered version)3:
authenticate(options) {
return new Ember.RSVP.Promise((res) => {
// the callback that will be executed upon authentication
var authCb = (err, profile, jwt, accessToken, state, refreshToken) => {
if (err) {
this.onAuthError(err);
} else {
var sessionData = { profile, jwt, accessToken, refreshToken };
this.afterAuth(sessionData).then(response => res(this._setupFutureEvents(response)));
}
};
var lock = this.get('lock');
// see if there's a SSO session available
lock.$auth0.getSSOData(function(err, data) {
if (!err && data.sso) {
// there is! redirect to Auth0 for SSO
options.authParams.callbackOnLocationHash = true;
lock.$auth0.signin(options.authParams, authCb);
} else {
// regular login
lock.show(options, authCb);
}
});
});
}
This behaves mostly as I would expect it to. When I log in with an existing session from another SSO-enabled app on the same domain, if (!err && data.sso) resolves to true, and lock.$auth0.signin(options.authParams, authCb) is called. However, this signin logic is not working as intended. Auth0.signin calls the Auth0.authorize method, which generates a target URL that looks something like:
https://mydomain.auth0.com/authorize?scope=openid&response_type=token&callbackOnLocationHash=true&sso=true&client_id=(MyClientIdHash)&redirect_uri=localhost%23access_token%3(MyAccessToken)%26id_token%3(MyIdToken1).(MyIdToken2).(MyIdToken3)token_type%3DBearer&auth0Client=(MyAuth0Client)
My application is then redirected to this URL for authorization. I get a 302 and am redirected back to the callback URL (my root page). Because there is a new page transition, if (!get(session, 'isAuthenticated')) is hit again. It returns false, and so the same logic repeats itself, looping indefinitely.
Does anyone have any insight on what I might be doing incorrectly here? The authorize endpoint seems to behave as if I were being authenticated, but then the authentication is never actually triggered. I've debugged through this code fairly extensively but seen no obvious red flags, and I've followed provided examples closely enough that I'm not sure what I would change. I'm not entirely sure where the failure to authenticate is happening such that get(session, 'isAuthenticated') is false.
I'm using Oauth2 on my own Web API and ASP.NET C# to consume that API on a web app. On my web app, I'm making HttpWebRequests. When my access token expires, I'm calling a method "RefreshToken" that makes a request to get a new access token. This works beautifully without issue...except that the response I get back contains a new refresh token??? I was expecting just the new access token. I didn't even think this was possible without passing credentials again, but my grant_type=refresh_token is somehow generating a new refresh token, and it has me concerned.
Please see this post by Taiseer Joudeh (which is a phenomenal series of posts by the way).
You will find in the SimpleRefreshTokenProvider's CreateAsync method, the refresh token is deleted and re-created which provides "sliding expiration". If you don't want a new refresh token each time don't delete/recreate.
Here is the line of code I'm talking about:
var result = await tokenRepository.AddRefreshToken(token);
AddRefreshToken actually deletes and re-creates the token as seen here:
public async Task<bool> AddRefreshToken(AspNetRefreshToken token)
{
var existingToken = _context.AspNetRefreshTokens.SingleOrDefault(r => r.Subject == token.Subject && r.ClientId == token.ClientId);
if (existingToken != null)
{
await RemoveRefreshToken(existingToken);
}
_context.AspNetRefreshTokens.Add(token);
return await _context.SaveChangesAsync() > 0;
}
So again, without seeing your code I would say its working as expected. If you don't want sliding expiration, don't have the provider re-create the refresh token each time.
I have a working oauth2 authentication process where I get an access token (eg from facebook) using ember simple auth, send it to the back end which calls fb.me() and then uses JWT to create a token. This token is then sent back to the ember app, which then has to send it with every server request, include those requests made by ember-data.
I also need to have this token available after a browser reload.
I have tried many options, where I set a property 'authToken' on the session - I believe that this uses local storage to persist the authenticated session.
But I always seem to have trouble with coordinating the retrieval of this token - either I don't have access to the session, or the token is no longer on the session, or I can't change the ember data headers.
Does anyone have a working simple example of how this can be done - I think it should be easy, but I'm obviously missing something!
Thanks.
Update
The only thing I've been able to get working is to use torii as shown below, but the session content is still lost on refresh - I can see its still authenticated, but its lost the token I set here. So I'm still looking for a real solution.
authenticateWithGooglePlus: function () {
var self = this;
this.get('session').authenticate('simple-auth-authenticator:torii', 'google-oauth2')
.then(function () {
resolveCodeToToken(self.get('session'), self);
});
}
resolveCodeToToken gets the bearer token from the server, sets it on the session and then transitions to the protected page:
function resolveCodeToToken(session, route) {
var authCode = session.content.authorizationCode;
var type = session.content.provider.split('-')[0];
$.ajax({
url: 'http://localhost:4200/api/1/user/auth/' + type,
data: {authCode: authCode}
}).done(function (response) {
// todo handle invalid cases - where user is denied access eg user is disabled
session.set('authToken', response.token);
route.transitionTo('activity', moment().format('DDMMYYYY'));
});
}
And I have a custom authorizer for putting the token (stored in the session) on every request:
import Base from 'simple-auth/authorizers/base';
export default Base.extend({
authorize: function(jqXHR, requestOptions) {
var accessToken = this.get('session.content.authToken');
if (this.get('session.isAuthenticated') && !Ember.isEmpty(accessToken)) {
jqXHR.setRequestHeader('Authorization', accessToken);
}
}
});
I'm not sure why this.get('session.content.authToken') would be undefined after a refresh, I thought by default the session was persisted in local storage. The fact that it is authenticated is persisted, but thats useless without the token since the server will reject calls to protected endpoints.
You'd want to implement your own custom authenticator that first gets a token from Facebook and then sends that to your own server to exchange it for a token for your app. Once you have that you get authorization of ember-data requests as well as session persistence etc. for free.
Have a look at this example: https://github.com/simplabs/ember-simple-auth/blob/master/examples/7-multiple-external-providers.html