Access token and authentication for guest user
TLDR:
is it possible to have guest account, like guest@organization.onmicrosoft.com, at company's MS Office 365 cloud that will have "read" permission to organization's users calendars and events with constant access token? By constant access token I mean that I sign in once for this guest user and receive constant access token from Azure AD (like application access authentication but as guest account).
I have my own company's MS Office 365 account with some users in it. There is one global administrator account and few regular users.
There is second company, let's call it XYZ, with their own MSO365 account with many of administrators and users. Big company.
Now I'm writing simple app where I need to have access to read XYZ company's users calendars and events. I have list of required users in my app with proper MSO365 ID's.
I think that 'read' privilege is enough since we can send invitation for events through ordinary email message.
My App will read user events through MS Graph API etc. with some logic and realease it (send invitations for events etc.) with CRON jobs.
And here is my problem with authentication.
I don't want to have "application access" Azure AD privileges at my App. I know the XYZ company security policy won't apply it since "application access" gives access to all accounts at organization. Application access means that XYZ company's global administrator apply application privileges for my App by single sign in into Azure AD. If he do so i have Access token which i can use for API calls at my app withoud need of additional authentication.
I can't use "user access" Azure AD authentication neither.
Due to my CRON jobs and API calls which fire then.
User access means that user need sign in at Azure AD login service what gives me Access token and Refresh token for API calls. Those tokens are 1 hour lifetime.
So I though about: if there is possibility to have a guest account at XYZ company's MSO365 that would let me use authentication mechanism like the "application access"?
By this I mean that XYZ company's global Admin creates me a guest account like guest@xyz.onmicrosoft.com which will have access to read users calendar and events. What is more I need this account to have constant access token which I can use in my cron job's api calls with no need to sign in at Azure AD.
The question is: is it possible? If so how to do it?
azure azure-active-directory office365 microsoft-graph office365api
add a comment |
TLDR:
is it possible to have guest account, like guest@organization.onmicrosoft.com, at company's MS Office 365 cloud that will have "read" permission to organization's users calendars and events with constant access token? By constant access token I mean that I sign in once for this guest user and receive constant access token from Azure AD (like application access authentication but as guest account).
I have my own company's MS Office 365 account with some users in it. There is one global administrator account and few regular users.
There is second company, let's call it XYZ, with their own MSO365 account with many of administrators and users. Big company.
Now I'm writing simple app where I need to have access to read XYZ company's users calendars and events. I have list of required users in my app with proper MSO365 ID's.
I think that 'read' privilege is enough since we can send invitation for events through ordinary email message.
My App will read user events through MS Graph API etc. with some logic and realease it (send invitations for events etc.) with CRON jobs.
And here is my problem with authentication.
I don't want to have "application access" Azure AD privileges at my App. I know the XYZ company security policy won't apply it since "application access" gives access to all accounts at organization. Application access means that XYZ company's global administrator apply application privileges for my App by single sign in into Azure AD. If he do so i have Access token which i can use for API calls at my app withoud need of additional authentication.
I can't use "user access" Azure AD authentication neither.
Due to my CRON jobs and API calls which fire then.
User access means that user need sign in at Azure AD login service what gives me Access token and Refresh token for API calls. Those tokens are 1 hour lifetime.
So I though about: if there is possibility to have a guest account at XYZ company's MSO365 that would let me use authentication mechanism like the "application access"?
By this I mean that XYZ company's global Admin creates me a guest account like guest@xyz.onmicrosoft.com which will have access to read users calendar and events. What is more I need this account to have constant access token which I can use in my cron job's api calls with no need to sign in at Azure AD.
The question is: is it possible? If so how to do it?
azure azure-active-directory office365 microsoft-graph office365api
add a comment |
TLDR:
is it possible to have guest account, like guest@organization.onmicrosoft.com, at company's MS Office 365 cloud that will have "read" permission to organization's users calendars and events with constant access token? By constant access token I mean that I sign in once for this guest user and receive constant access token from Azure AD (like application access authentication but as guest account).
I have my own company's MS Office 365 account with some users in it. There is one global administrator account and few regular users.
There is second company, let's call it XYZ, with their own MSO365 account with many of administrators and users. Big company.
Now I'm writing simple app where I need to have access to read XYZ company's users calendars and events. I have list of required users in my app with proper MSO365 ID's.
I think that 'read' privilege is enough since we can send invitation for events through ordinary email message.
My App will read user events through MS Graph API etc. with some logic and realease it (send invitations for events etc.) with CRON jobs.
And here is my problem with authentication.
I don't want to have "application access" Azure AD privileges at my App. I know the XYZ company security policy won't apply it since "application access" gives access to all accounts at organization. Application access means that XYZ company's global administrator apply application privileges for my App by single sign in into Azure AD. If he do so i have Access token which i can use for API calls at my app withoud need of additional authentication.
I can't use "user access" Azure AD authentication neither.
Due to my CRON jobs and API calls which fire then.
User access means that user need sign in at Azure AD login service what gives me Access token and Refresh token for API calls. Those tokens are 1 hour lifetime.
So I though about: if there is possibility to have a guest account at XYZ company's MSO365 that would let me use authentication mechanism like the "application access"?
By this I mean that XYZ company's global Admin creates me a guest account like guest@xyz.onmicrosoft.com which will have access to read users calendar and events. What is more I need this account to have constant access token which I can use in my cron job's api calls with no need to sign in at Azure AD.
The question is: is it possible? If so how to do it?
azure azure-active-directory office365 microsoft-graph office365api
TLDR:
is it possible to have guest account, like guest@organization.onmicrosoft.com, at company's MS Office 365 cloud that will have "read" permission to organization's users calendars and events with constant access token? By constant access token I mean that I sign in once for this guest user and receive constant access token from Azure AD (like application access authentication but as guest account).
I have my own company's MS Office 365 account with some users in it. There is one global administrator account and few regular users.
There is second company, let's call it XYZ, with their own MSO365 account with many of administrators and users. Big company.
Now I'm writing simple app where I need to have access to read XYZ company's users calendars and events. I have list of required users in my app with proper MSO365 ID's.
I think that 'read' privilege is enough since we can send invitation for events through ordinary email message.
My App will read user events through MS Graph API etc. with some logic and realease it (send invitations for events etc.) with CRON jobs.
And here is my problem with authentication.
I don't want to have "application access" Azure AD privileges at my App. I know the XYZ company security policy won't apply it since "application access" gives access to all accounts at organization. Application access means that XYZ company's global administrator apply application privileges for my App by single sign in into Azure AD. If he do so i have Access token which i can use for API calls at my app withoud need of additional authentication.
I can't use "user access" Azure AD authentication neither.
Due to my CRON jobs and API calls which fire then.
User access means that user need sign in at Azure AD login service what gives me Access token and Refresh token for API calls. Those tokens are 1 hour lifetime.
So I though about: if there is possibility to have a guest account at XYZ company's MSO365 that would let me use authentication mechanism like the "application access"?
By this I mean that XYZ company's global Admin creates me a guest account like guest@xyz.onmicrosoft.com which will have access to read users calendar and events. What is more I need this account to have constant access token which I can use in my cron job's api calls with no need to sign in at Azure AD.
The question is: is it possible? If so how to do it?
azure azure-active-directory office365 microsoft-graph office365api
azure azure-active-directory office365 microsoft-graph office365api
asked Nov 16 '18 at 12:00
Igor W.
1087
1087
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The only way there (AFAIK) is to use refresh tokens.
Application-level access is more robust but requires organization-wide access.
So you use delegated access (user access), store refresh tokens somewhere.
You can use those tokens basically indefinitely,
however certain events can expire the refresh token.
It doesn't happen often, but it can happen.
In that case you would need the user to login again so you can get a new refresh token.
You should also store the new refresh token that you get when you acquire tokens using a refresh token.
This new token can overwrite the old token for that user.
And of course keep in mind refresh tokens are user-specific so you gotta store one for each user.
This is the approach that one of our bigger apps takes.
If we fail to acquire a token in the background process,
that user gets a flag set on them that their token does not work,
and they'll get a notification that they need to re-authenticate for the feature to start working again.
1
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53337491%2faccess-token-and-authentication-for-guest-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The only way there (AFAIK) is to use refresh tokens.
Application-level access is more robust but requires organization-wide access.
So you use delegated access (user access), store refresh tokens somewhere.
You can use those tokens basically indefinitely,
however certain events can expire the refresh token.
It doesn't happen often, but it can happen.
In that case you would need the user to login again so you can get a new refresh token.
You should also store the new refresh token that you get when you acquire tokens using a refresh token.
This new token can overwrite the old token for that user.
And of course keep in mind refresh tokens are user-specific so you gotta store one for each user.
This is the approach that one of our bigger apps takes.
If we fail to acquire a token in the background process,
that user gets a flag set on them that their token does not work,
and they'll get a notification that they need to re-authenticate for the feature to start working again.
1
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
add a comment |
The only way there (AFAIK) is to use refresh tokens.
Application-level access is more robust but requires organization-wide access.
So you use delegated access (user access), store refresh tokens somewhere.
You can use those tokens basically indefinitely,
however certain events can expire the refresh token.
It doesn't happen often, but it can happen.
In that case you would need the user to login again so you can get a new refresh token.
You should also store the new refresh token that you get when you acquire tokens using a refresh token.
This new token can overwrite the old token for that user.
And of course keep in mind refresh tokens are user-specific so you gotta store one for each user.
This is the approach that one of our bigger apps takes.
If we fail to acquire a token in the background process,
that user gets a flag set on them that their token does not work,
and they'll get a notification that they need to re-authenticate for the feature to start working again.
1
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
add a comment |
The only way there (AFAIK) is to use refresh tokens.
Application-level access is more robust but requires organization-wide access.
So you use delegated access (user access), store refresh tokens somewhere.
You can use those tokens basically indefinitely,
however certain events can expire the refresh token.
It doesn't happen often, but it can happen.
In that case you would need the user to login again so you can get a new refresh token.
You should also store the new refresh token that you get when you acquire tokens using a refresh token.
This new token can overwrite the old token for that user.
And of course keep in mind refresh tokens are user-specific so you gotta store one for each user.
This is the approach that one of our bigger apps takes.
If we fail to acquire a token in the background process,
that user gets a flag set on them that their token does not work,
and they'll get a notification that they need to re-authenticate for the feature to start working again.
The only way there (AFAIK) is to use refresh tokens.
Application-level access is more robust but requires organization-wide access.
So you use delegated access (user access), store refresh tokens somewhere.
You can use those tokens basically indefinitely,
however certain events can expire the refresh token.
It doesn't happen often, but it can happen.
In that case you would need the user to login again so you can get a new refresh token.
You should also store the new refresh token that you get when you acquire tokens using a refresh token.
This new token can overwrite the old token for that user.
And of course keep in mind refresh tokens are user-specific so you gotta store one for each user.
This is the approach that one of our bigger apps takes.
If we fail to acquire a token in the background process,
that user gets a flag set on them that their token does not work,
and they'll get a notification that they need to re-authenticate for the feature to start working again.
answered Nov 16 '18 at 12:23
juunas
21k34477
21k34477
1
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
add a comment |
1
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
1
1
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
Ok, if there are no more answers I'm accepting Yours @juunas. Thanks a lot!
– Igor W.
Nov 19 '18 at 13:22
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53337491%2faccess-token-and-authentication-for-guest-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown