I'm developing a new accounts-*** package for an API which uses an authorization header rather than an access_token parameter (as is done by most other APIs/packages I've seen). However, every version I've attempted has resulted in a 401 being returned. I've tried a few variations to no avail (Authorization in quotes/without quotes, declaring the accessToken as a new variable inside the funtion, etc.). Am I missing something obvious?
////////////////////////////////////////////////
// packages/newApi/newApi_server.js
////////////////////////////////////////////////
// Other steps for exchanging auth code for access and refresh tokens
var getIdentity = function(accessToken){
var accessTokenString = 'Bearer ' + accessToken;
try {
return HTTP.get("https://testapi.testing.com/user/info", {
headers: {
'Authorization': accessTokenString
}
}).data;
} catch(err) {
throw_.extend(new Error('You done goofed. ' + err.message));
}
};
Edit: I had tried securing my accessToken earlier in the OAuth flow which was breaking the identity fetching.
As I explained in the edit, it was a silly encoding/encryption mistake. Make sure your access tokens are properly accessible.
Related
I am getting lost with Outlook addin development and really need some help.
I have developed an addin that sends selected email to another server via REST API and it worked fine, but there was a limitation to 1MB so I tried to develop a solution that use ewsURL + SOAP but faced with CORS issues.
Now I got a suggestion to use GRAPH approach (fine with me) but I have no idea how that suppose to work using JavaScript.
Basically I need to get an email as MIME/EML format.
I was guided to check this article: https://learn.microsoft.com/en-us/graph/outlook-get-mime-message
There is endpoint that looks promissing:
https://graph.microsoft.com/v1.0/me/messages/4aade2547798441eab5188a7a2436bc1/$value
But I do not see explanation
how to make authorization process?
I have tried to get token from getCallbackTokenAsync but that did not work
I have tried Office.context.auth.getAccessTokenAsync but getting an issue:
Error code: 13000 Error name: API Not Supported.
Error message: The identity API is not supported for this add-in.
how to get email id
I have tried to do Office.context.mailbox.item.itemId but it looks different compare to what I have seen in the examples (but hopefully that is not a problem)
Please help :-)
There are 2 solutions here. It is preferred longer term to use graph end point with https://learn.microsoft.com/en-us/office/dev/add-ins/develop/authorize-to-microsoft-graph and you can use https://graph.microsoft.com/v1.0/me/messages/4aade2547798441eab5188a7a2436bc1/$value. However this solution requires a backend / service . Transferring through backend is preferable for large content so the content can transfer directly from Exchange to the service.
Alternatively, you can get token from getCallbackTokenAsync, from this doc: https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/use-rest-api
As you noted is that you will need to translate the ews id using convertToRestId. Putting together, your solution should look something like this:
Office.context.mailbox.getCallbackTokenAsync({isRest: true}, function(result){
if (result.status === "succeeded") {
let token = result.value;
var ewsItemId = Office.context.mailbox.item.itemId;
const itemId = Office.context.mailbox.convertToRestId(
ewsItemId,
Office.MailboxEnums.RestVersion.v2_0);
// Request the message's attachment info
var getMessageUrl = Office.context.mailbox.restUrl +
'/v2.0/me/messages/' + itemId + '/$value';
var xhr = new XMLHttpRequest();
xhr.open('GET', getMessageUrl);
xhr.setRequestHeader("Authorization", "Bearer " + token);
xhr.onload = function (e) {
console.log(this.response);
}
xhr.onerror = function (e) {
console.log("error occurred");
}
xhr.send();
}
});
I'm not sure how to explain this succinctly, first part, Implicit flow. I don't exactly understand what implicit flow is. I haven't distilled it down in to a single sentence. Is it a design pattern or a way of handling tokens, both, I dunno.
Working with a pretty basic JavaScript Single Page Application and implementing Msal version 1.2.1. Each time an msalClient gets a token for a scope it leaves behind an iFrame to handle token refreshing.
window.msalConfig = {
auth: {
clientId: '<clientId>'
, authority: "https://login.microsoftonline.com/common"
, validateAuthority: true
}
, cache: {
cacheLocation: "localStorage"
}
, graphScope: {
scopes: ["https://graph.microsoft.com/User.Read", "https://graph.microsoft.com/Mail.Send" ]
}
, appScope: {
scopes: ["<clientId>"]
}
, appToken:{
token: null
}
, graphToken:{
token: null
}
};
clientApplication = new Msal.UserAgentApplication(window.msalConfig);
function onSignin(idToken) {
clientApplication.acquireTokenSilent(window.msalConfig.appScope)
.then(function (token) {
window.msalConfig.appToken.token = token;
}, function (error) {
clientApplication.acquireTokenPopup(window.msalConfig.appScope).then(function (token) {
window.msalConfig.appToken.token = token;
}, function (error) {
console.log(error);
});
});
getGraphToken();
};
function getGraphToken() {
clientApplication.acquireTokenSilent(window.msalConfig.graphScope)
.then(function (token) {
window.msalConfig.graphToken.token = token;
}), function (error) {
console.log(error);
};
};
These iFrames just sit here and refresh periodically, presumably getting a new token, or keeping it alive on the other end. (When in the chrome debugger each refresh throws me to the Sources tab, this is makes debugging nearly impossible.)
Also, wondering why cross site cookie errors are being thrown when working with the Graph Scope but not the App Scope.
Curious why this is closed, This still seems to be present.
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/697
The Implicit Flow is one of the flows for acquiring tokens in OAuth, and is especially well-suited for single-page applications, as it does not require a server component. As you observed, it uses iframes to acquire tokens. You can read more about the Implicit Flow here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow
The SameSite cookie warnings are expected, as there are some cookies on login.microsoftonline.com have been intentionally left without the SameSite attribute. All of the cookies for login.microsoftonline.com that are needed for authentication have been updated. You can read more here: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-handle-samesite-cookie-changes-chrome-browser?tabs=dotnet
For issue 697, the main issue of your application being reloaded in a hidden iframe has been addressed in v1.2.0, which now allows you to specify a page without MSAL or any other content (e.g. a blank html page) as your redirect URI, which mitigates the performance overhead of reloading your application in the iframe/popup. You can also set your redirect URI per request, in case you need a different URI that the one set in the configuration.
And if you find iframes difficult to debug, know that we are working a new version of the library which will use the Auth Code Flow w/ PKCE (instead of the Implicit Flow) to acquire tokens, which will use CORS http requests to obtain tokens, instead of iframes. We are planning to have that available this month.
I would like your opinion in order to achieve something. I have an api and I want to restrictionate the access of the user. But short story long, in action login controller of page /login I generate the token for the user autheticated and I return it. Well, here comes one of my question/problem. It's mandatory in a action controller to return a response, and my token it's send in json format and it's displayed on browser, but I don't want this, I just want to keep in response or in something so that my angular part to take that token and to take care of it in its way. So my method login:
public function loginAction(Request $request)
{
$username= $this->get('security.token_storage')->getToken()->getUser()->getEmail();
$serviceUser = $this->container->get('ubb_user_login');
$tokenUser = $serviceUser->generateToken($username);
$response = new JsonResponse(array('Token' => $tokenUser));
return $response;
}
2nd problem. I do not know in angular where to extract the token. In a controller I tried something:
app.controller('loginApi', function ($scope, $http, $window){
$http.get(
'/api/user/login'
).then(function (success) {
$scope.token = success.data.Token;
$window.localStorage.setItem('Token', token); // it's okay used like this localStorage?
});
});
Here, I want only to take the token from /login action, to save it in local storage, and then to display it on every request using $http request interceptor. That part works. If I send a random string in header auth it's working and it gives me access to api:
function httpInterceptor() {
return {
request: function(config) {
config.headers.authorization = 'jdjdnnkdkd';
return config;
},
responseError: function(errorResponse) {
switch (errorResponse.status) {
case 403:
window.location = '/login';
break;
case 401:
window.location = '/login';
}
return $q.reject(errorResponse);
}
}
}
So, the problems I encounter:
1) How to send the token in order for angular to take it, but to not be displayed in the browser? Let's say that I have a menu that access the api, and if the user it's not authenticated,clicking on a link unauthenticated it's sending me on the login page, and after I auth with success, to redirect me on the menu?
2) After returning the token, where exactly to use it in angular? In which controller? And how to save it?
Much appreciation, thank you.
It seems like you need a separate api resource for working with the tokens. Have you tried using FOSOAuthServeBundle? It helps a lot with setting up oauth authentication, tokens etc.
In general you need to have a separate call for the token, i.e.:
angluar app makes request to a get token resource, a token is returned and temporarily stored in the angular app
use that token for each subsequent request - check the oauth bundle config on how to set which urls have to be oauth protected, but that bundle takes care of this for you
Regarding your angular issue, look at this q/a How to store authentication bearer token in browser cookie using AngularJS
I've gone through plenty of Google documentation and SO Q/A's but with no luck. I wonder if anyone has yet succesfully used the OpenId to OpenId Connect migration as advised by Google.
This is what we used to do:
IAuthenticationResponse response = _openid.GetResponse();
if (response != null) {
//omitted for brevity
} else {
IAuthenticationRequest req = _openid.CreateRequest("https://www.google.com/accounts/o8/id");
req.AddExtension(new ClaimsRequest
{
Country = DemandLevel.Request,
Email = DemandLevel.Request,
Gender = DemandLevel.Require,
PostalCode = DemandLevel.Require,
TimeZone = DemandLevel.Require
});
req.RedirectToProvider();
}
That was done using a version of DotNetOpenAuth that dates back a few years. Because Google has deprecated OpenId authentication we are trying to move over to OpenID Connect. The key question here is: can I somehow get my hands on the OpenId identifier (in the form of https://www.google.com/accounts/o8/id?id=xyz) using the latest version of DotNetOpenAuth library or by any other means?
I have tried the latest DotNetOpenAuth and I can get it to work but it gives me a new Id (this was expected). I have also tried the Javascript way by using this URL (line breaks for readibility):
https://accounts.google.com/o/oauth2/auth?
scope=openid%20profile%20email
&openid.realm=http://localhost/palkkac/
&client_id=//here is the client id I created in google developer console
&redirect_uri=http://localhost/palkkac/someaspxpagehere
&response_type=id_token%20token
I checked (using Fiddler) the realm value that we currently send using the old DotNetOpenAuth code and it is http://localhost/palkkac/. I've put the same realm in the url above. The redirect url starts with the realm value but it is not entirely the same.
When I redirect to a simple page that parses the id_token and decrypts it (using the https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=zyx endpoint) I get this:
audience "client id is here"
email "mikkark#gmail.com"
expires_in 3597
issued_at //some numbers here
issued_to "client id is here"
issuer "accounts.google.com"
user_id "here is a sequence of numbers, my id in the OpenID Connect format that is"
verified_email true
So there is no sign of the openid_id field that you would expect to find here, though the whole structure of the message seems different from the Google docs, there is no field titled sub, for example. I wonder if I'm actually using the wrong endpoint, parameters or something?
What I have been reading is the migration guide: https://developers.google.com/accounts/docs/OpenID. I skipped step 2 because it seemed like an optional step. In step 3 the field openid_id is discussed and I would like to get that to work as a proof-of-concept first.
We registered the app on Google in order to create the client id etc. There are now also numerous allowed redirect url's as well as javascript origins listed in the Google dev console. Let me know if those might mess up the system and I'll post them here for review.
Side note: we are supposed to be moving our app behind a strictly firewalled environment where we would need to open ports in order to do this on the server side. Therefore, a client-side Javascript solution to access Google combined with HTTPS and redirecting the result to the server would be prefered (unless there are other issues that speak against this).
There are other resources on SO regarding this same issue, although all of these seem to use different libraries on the server side to do the job and nobody seems to have made any attempts at using Javascript:
Here (https://stackoverflow.com/questions/22842475/migrating-google-openid-to-openid-connect-openid-id-does-not-match) I think the problem was resolved by setting the realm to be the same as in the old OpenId2.0 flow. This does not seem to work in my case.
over here the openid_id field is also missing, but the problem here is more about how to request the id_token from Google using libraries other than DotNetOpenAuth.
and in here there seem to be similar problems getting Google to return the openid_id field.
You can use the GoogleAuthentication owin middleware.
app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions
{
SignInAsAuthenticationType = signAs,
AuthenticationType = "Google",
ClientId = "xxx.apps.googleusercontent.com",
ClientSecret = "xx",
CallbackPath = PathString.FromUriComponent("/oauth2callback"),
Provider = new GoogleOAuth2AuthenticationProvider
{
OnApplyRedirect = context =>
{
context.Response.Redirect(context.RedirectUri + "&openid.realm=https://mydomain.com/"); // DotNetOpenAuth by default add a trailing slash, it must be exactly the same as before
}
},
BackchannelHttpHandler = new MyWebRequestHandler()
}
Then, add a new class called MyWebRequestHandler:
public class MyWebRequestHandler : WebRequestHandler
{
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
var httpResponse = await base.SendAsync(request, cancellationToken);
if (request.RequestUri == new Uri("https://www.googleapis.com/plus/v1/people/me")) return httpResponse;
var configuration = await OpenIdConnectConfigurationRetriever.GetAsync("https://accounts.google.com/.well-known/openid-configuration", cancellationToken); // read the configuration to get the signing tokens (todo should be cached or hard coded)
// google is unclear as the openid_id is not in the access_token but in the id_token
// as the middleware dot not expose the id_token we need to parse it again
var jwt = httpResponse.Content.ReadAsStringAsync().Result;
JObject response = JObject.Parse(jwt);
string idToken = response.Value<string>((object)"id_token");
JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler();
try
{
SecurityToken token;
var claims = tokenHandler.ValidateToken(idToken, new TokenValidationParameters()
{
ValidAudience = "xxx.apps.googleusercontent.com",
ValidIssuer = "accounts.google.com",
IssuerSigningTokens = configuration.SigningTokens
}, out token);
var claim = claims.FindFirst("openid_id");
// claim.Value will contain the old openid identifier
if (claim != null) Debug.WriteLine(claim.Value);
}
catch (Exception ex)
{
Debug.WriteLine(ex.ToString());
}
return httpResponse;
}
}
If like me you found this not really straightforward, please help by upvoting this issue https://katanaproject.codeplex.com/workitem/359
I'm trying to create a user account through the apigee JS API. This worked just fine when I was last doing this before the holidays in mid December. Now, however, I get a 401 Unauthorized error reading token_expired.
Is there a way to refresh the token? I don't know why it would have expired.
This is what I'm trying. First I instantiate the data client. No problems here:
var dataClient;
var client_creds = {
orgName: '*******',
appName: '*******'
}
dataClient = new Apigee.Client(client_creds);
Later, when trying to create a new user, I get the token_expired error:
dataClient.request(options, function (error, response) {
if (error) {
console.log(response);
alert("Something went wrong when trying to create the user. " + response.error)
// Error
} else {
// Success - the user has been created, now login.
dataClient.login(user.email, user.password,
function (err) {
if (err) {
//error - could not log user in
console.log("There was an error logging in " + user.name);
} else {
//success - user has been logged in
}
}
);
}
});
I've also tried dataClient.signup, but same error.
There are no refresh tokens within App Services; you'll need to follow the login flow in order to retrieve a new token. Note that you can specify the ttl parameter, like so, so you don't need to do this as frequently:
https://api.usergrid.com/{org}/{app}/token?ttl=604800
By default, this is set to 7 days, but you can change the default app max ttl to 0 (non-expiring) or something else like 31104000000 (365 days).
To do that, you make a PUT request:
https://api.usergrid.com/{org}/{app}/?client_id={app_client_id}&client_secret={app_client_secret}
With JSON payload:
{
"accesstokenttl":0
}
Or for 1 year:
{
"accesstokenttl":31104000000
}
If that doesn't work for you, the authorization tokens for the JavaScript SDK are kept in your browser's local storage. In Chrome, use the Developer Tools. In the Resources tab on the left hand side expand the Local Storage entry. You should see something like "http://usergrid.dev" or something similar. Choose that and on the right hand side you should see an entry for accessToken. Delete that and it should solve your problem.