This article explains in detail how Modern Authentication works with the new firmware release UCS5.5.1 for the Polycom VVX family of handsets in an ADFS Federated Identity environment. Polycom VVX phones are a family of Office365 qualified IP phones for Skype for Business. First we go recap some of the basics of what Modern Authentication is and how it works and then show the user experience of the phone user interface during sign-in using modern authentication via the Web Sign-in method available in UCS5.5.1. Fellow MVP Jeff Schertz has covered all the new phone features for this firmware release in his blog post here and thus will not be repeated in this article. We will also provide some debug logs captured on the phone during the sign-in process which may assist in troubleshooting if something does not work.
What is Modern Authentication and why use it?
Modern Authentication is a new method of granting access to all Office365 workloads for a wide range of client platforms including Office2016, Skype for Business 2016 as well as mobile devices running Windows, iOS and Android. It is the newer and preferred method for accessing Office365 workloads such as Skype for Business Online and Exchange Online in comparison to legacy authentication methods based on the Microsoft Online Sign-in Assistant (OrgID) or basic authentication. To align with Microsoft's strategy, Polycom has already started to use modern authentication for its VVX family of IP Phones in UCS 5.5.1 and in the very near future, also for Polycom Group Series room systems as well which is currently undergoing Office365 qualification testing. Modern Authentication is based on OAuth2.0 which is an open standard for token-based authentication and authorization particularly suited for cloud services on the internet because it gives identity providers with the ability to grant third-party access to web resources without sharing a password. OAuth was first released in 2007 as an authentication method for the Twitter API and in 2010, the IETF OAuth Working Group published OAuth 2.0, an improved version of OAuth with new features such as new flows, simplified signatures and short-lived tokens with long-lived authorizations. In Office365, these tokens are known as Access Tokens and Refresh Tokens respectively. Another advantage of using OAuth is the ability to support 3rd party STS providers such OKTA and Centrify as well as Multi-Factor Authentication (MFA). OAuth was originally created for web-based applications and so for rich clients such as Office2016, Microsoft provides the .NET Framework Active Directory Authentication Library (ADAL) that these applications can use to access Office365 workloads authenticating against the STS service Azure AD and an on-premise AD deployment via ADFS as described in this environment. At a high level, the OAuth authorization flow can be illustrated in the diagram below:
Modern Authentication is a new method of granting access to all Office365 workloads for a wide range of client platforms including Office2016, Skype for Business 2016 as well as mobile devices running Windows, iOS and Android. It is the newer and preferred method for accessing Office365 workloads such as Skype for Business Online and Exchange Online in comparison to legacy authentication methods based on the Microsoft Online Sign-in Assistant (OrgID) or basic authentication. To align with Microsoft's strategy, Polycom has already started to use modern authentication for its VVX family of IP Phones in UCS 5.5.1 and in the very near future, also for Polycom Group Series room systems as well which is currently undergoing Office365 qualification testing. Modern Authentication is based on OAuth2.0 which is an open standard for token-based authentication and authorization particularly suited for cloud services on the internet because it gives identity providers with the ability to grant third-party access to web resources without sharing a password. OAuth was first released in 2007 as an authentication method for the Twitter API and in 2010, the IETF OAuth Working Group published OAuth 2.0, an improved version of OAuth with new features such as new flows, simplified signatures and short-lived tokens with long-lived authorizations. In Office365, these tokens are known as Access Tokens and Refresh Tokens respectively. Another advantage of using OAuth is the ability to support 3rd party STS providers such OKTA and Centrify as well as Multi-Factor Authentication (MFA). OAuth was originally created for web-based applications and so for rich clients such as Office2016, Microsoft provides the .NET Framework Active Directory Authentication Library (ADAL) that these applications can use to access Office365 workloads authenticating against the STS service Azure AD and an on-premise AD deployment via ADFS as described in this environment. At a high level, the OAuth authorization flow can be illustrated in the diagram below:
User Experience with VVX Web Sign-in via ADFS using Modern Authentication
To begin the sign-in experience walkthrough, on a VVX phone the user first selects the Web Sign-in Option shown below on the left. The phone will contact the online service to get a unique keycode and will display this keycode along with the browser URL shown below on the right:
To begin the sign-in experience walkthrough, on a VVX phone the user first selects the Web Sign-in Option shown below on the left. The phone will contact the online service to get a unique keycode and will display this keycode along with the browser URL shown below on the right:
 |  |
On the phone, this process can be seen in the following log entries:
0222131959|Devic|2|00|Sent request for Device Configuration:https://bootstrap.pinauth.services.skypeforbusiness.com:443/api/DeviceConfig/Polycom/Default?api-version=1.0 (0X1136179904)
0222131959|Devic|2|00|S/E(sSDevicePairGetAADUrlAndClientID,kBaseEventInit),rO(5)
0222131959|Devic|2|00|<\SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((304),(5),Ticks(0))
0222132000|Devic|2|00|<SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((304),(301)kEDevicePairOnRecvDataResponse,Ticks(0))
0222132000|Devic|2|00|parseAndSaveRequiredInfo -> eRequestID (1)
0222132000|Devic|2|00|DeviceConfiguration Data: AadEndpointUrl[https://login.microsoftonline.com/] ClientId[131c22db-3591-4fc8-a305-55444fa5ccd3] DevicePairingWebsiteUrl[http://aka.ms/sphone] GraphAPIUrl [https://graph.windows.net] AutoDiscoverUrl [https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root?] ExchangeOnlineAutoDUrl [https://outlook.office365.com/]
...
0222132001|Devic|2|00|parseDeviceInformation: user_code[HPMVGCDTX] device_code[HAQABAAEAAADRNYRQ3dhRSrm-4K-adpCJY-WmFgs_D0UqCU-R1ZU7WsOLHlGH2qgAd7j2LpZXFKHYAKkHNk8238TOCU3J5IyjyLJJy9BN27L3t7LnhohWeitj7dGTuVurO58IYwljpz7kEtcsVMXkbDNXADL9SeYRd0wr4uQl2ppyRSmNNzmHwyAA] verification_url[https://aka.ms/devicelogin] expires_in[900] interval[5]
Next the user users a browser to navigate to http://aka.ms/sphone which shows a Skype for Business Web Sign-in page asking for the address as shown on the left below. Here we need to enter the phone's SIP Address and then click on "Verify email". When the sign-in page detects that we are using an on-premise ADFS AD Federated identity, it then redirects the login to our ADFS Proxy server in the DMZ and provides a pop-up windows asking for credentials as shown on the right below:
0222131959|Devic|2|00|Sent request for Device Configuration:https://bootstrap.pinauth.services.skypeforbusiness.com:443/api/DeviceConfig/Polycom/Default?api-version=1.0 (0X1136179904)
0222131959|Devic|2|00|S/E(sSDevicePairGetAADUrlAndClientID,kBaseEventInit),rO(5)
0222131959|Devic|2|00|<\SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((304),(5),Ticks(0))
0222132000|Devic|2|00|<SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((304),(301)kEDevicePairOnRecvDataResponse,Ticks(0))
0222132000|Devic|2|00|parseAndSaveRequiredInfo -> eRequestID (1)
0222132000|Devic|2|00|DeviceConfiguration Data: AadEndpointUrl[https://login.microsoftonline.com/] ClientId[131c22db-3591-4fc8-a305-55444fa5ccd3] DevicePairingWebsiteUrl[http://aka.ms/sphone] GraphAPIUrl [https://graph.windows.net] AutoDiscoverUrl [https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root?] ExchangeOnlineAutoDUrl [https://outlook.office365.com/]
...
0222132001|Devic|2|00|parseDeviceInformation: user_code[HPMVGCDTX] device_code[HAQABAAEAAADRNYRQ3dhRSrm-4K-adpCJY-WmFgs_D0UqCU-R1ZU7WsOLHlGH2qgAd7j2LpZXFKHYAKkHNk8238TOCU3J5IyjyLJJy9BN27L3t7LnhohWeitj7dGTuVurO58IYwljpz7kEtcsVMXkbDNXADL9SeYRd0wr4uQl2ppyRSmNNzmHwyAA] verification_url[https://aka.ms/devicelogin] expires_in[900] interval[5]
Next the user users a browser to navigate to http://aka.ms/sphone which shows a Skype for Business Web Sign-in page asking for the address as shown on the left below. Here we need to enter the phone's SIP Address and then click on "Verify email". When the sign-in page detects that we are using an on-premise ADFS AD Federated identity, it then redirects the login to our ADFS Proxy server in the DMZ and provides a pop-up windows asking for credentials as shown on the right below:
 |  |
On the web browser we need to enter the unique keycode generated during the first step after which it will display a successful login on the web browser as shown in the diagrams below:
 |  |
Once the authentication flow is successful, the STS service in Azure AD will return a Refresh Token and an Access Token back to the phone. Again on the phone, this process can be seen in the following log entries:
0222132415|Devic|2|00|S/E(sSDevicePairGetRefreshAndIdTokens,),rO(5)
0222132415|Devic|2|00|<\SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((306),(5),Ticks(0))
0222132415|Devic|3|00|DevicePairingService's Ticked,Reason(Timer),Count/Size(1/1),Stop? (Yes)
0222132415|Devic|2|00|<SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((306),(301)kEDevicePairOnRecvDataResponse,Ticks(0))
0222132415|Devic|2|00|parseAndSaveRequiredInfo -> eRequestID (3)
0222132415|Devic|2|00|parseIDRefreshTokenData: access_token[eyJ0eXAiOiJKV1QiLCJh...] refresh_token[AQABAAAAAADRNYRQ3dhR...] id_token[eyJ0eXAiOiJKV1QiLCJh...]token_type [Bearer]
0222132415|Devic|2|00|S/E(sSDevicePairGetRefreshAndIdTokens,),rO(5)
0222132415|Devic|2|00|<\SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((306),(5),Ticks(0))
0222132415|Devic|3|00|DevicePairingService's Ticked,Reason(Timer),Count/Size(1/1),Stop? (Yes)
0222132415|Devic|2|00|<SM>(302)DevicePairingStateMachine(0x43b8bac0):Ctx((306),(301)kEDevicePairOnRecvDataResponse,Ticks(0))
0222132415|Devic|2|00|parseAndSaveRequiredInfo -> eRequestID (3)
0222132415|Devic|2|00|parseIDRefreshTokenData: access_token[eyJ0eXAiOiJKV1QiLCJh...] refresh_token[AQABAAAAAADRNYRQ3dhR...] id_token[eyJ0eXAiOiJKV1QiLCJh...]token_type [Bearer]
Having obtained the tokens, the phone proceeds to sign into Skype for Business Online and shortly will complete the sign in process and display the home page on the phone as shown below:
Again on the phone, this sign in process can be seen in the following log entries:
0222132535|sip |0|00| REGISTER sip:ucprimer.com;transport=tls SIP/2.0
0222132535|sip |0|00| Via: SIP/2.0/TLS 10.222.202.232:60618;branch=z9hG4bK323718ed169BD992
0222132535|sip |0|00| From: "vvx" <sip:[email protected]>;tag=B9A92F89-6F6343CE;epid=0004f2ae4b0d
0222132535|sip |0|00| To: <sip:[email protected]>
0222132535|sip |0|00| CSeq: 2 REGISTER
0222132535|sip |0|00| Call-ID: 7fae79d87a29829ae54a8b3071ae4b0d
0222132535|sip |0|00| Contact: <sip:[email protected]:60618;transport=tls>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:43a160e1-13ce-5cc6-804c-4a288a2c1873>"
0222132535|sip |0|00| User-Agent: Polycom/5.5.1.11526 PolycomVVX-VVX_600-UA/5.5.1.11526
0222132535|sip |0|00| Accept-Language: en
0222132535|sip |0|00| Ms-device-info: MAC=00-04-F2-AE-4B-0D, vendor=POLYCOM, version=PolycomVVX-VVX_600-5.5.1.11526
0222132535|sip |0|00| ms-keep-alive: UAC;hop-hop=yes
0222132535|sip |0|00| Supported: msrtc-event-categories,adhoclist,ms-cluster-failover,ms-userservices-state-notification,gruu-10,gruu
0222132535|sip |0|00| Event: registration
0222132535|sip |0|00| ms-subnet: 10.222.202.0
0222132535|sip |0|00| Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", targetname="SG20F03FES06.infra.lync.com", gssapi-data="FgMBAEQBAABAAwGS0Pl0EBC6TOz0gpjhtvXFtSAqobE5DDpeNvhd6Ls3MQAADgA5ADUAMwAvABYACgD/AQAACQAjAAAADwABAQ==", version=4
0222132535|sip |0|00| Max-Forwards: 70
0222132535|sip |0|00| Content-Length: 0
0222132535|sip |0|00|
0222132535|sip |0|00|>>> End of data send
0222132535|sip |1|00|CTcpSocket::SendData TLS queuedTxData = 0 TotalLen 1180 loop count 1 maxQueueDepth 40000
0222132535|sip |1|00|CTcpSocket::SendData TLS Sent 1180 loop count 1
0222132535|AuthS|0|00|Policy Dest:(201)AuthServicePolicyServiceKey:(102)AuthServiceUCMsgKey:(205)AuthSvcAOServiceRequestKey
Caller Service(-1):IndicationCode(0)
,TransactionID(-1)Data:SD:Key Data(User Key/Operation Key/Url Key):Uri:[email protected]
User/Domain:[email protected],
Url:
Operation:(102)AuthServiceUCMsgKey,Caller Service:(-1)Url,TransactionId:,-1
UrlKey(Operation,CallerService,Url):(-1),(-1),https://webpoolsg20f03.infra.lync.com:443/CertProv/CertProvisioningService.svc
Secondary Key:
Token Key/Data:TokenKey
0222132535|AuthS|0|00|Policy Dest:(201)AuthServicePolicyServiceKey:(102)AuthServiceUCMsgKey:(206)AuthSvcAOServiceReplyKey
Caller Service(-1):IndicationCode(200)Got User Certificate
,TransactionID(-1)Data:SD:Key Data(User Key/Operation Key/Url Key):Uri:[email protected]
User/Domain:[email protected],
Url:
Operation:(102)AuthServiceUCMsgKey,Caller Service:(-1)Url,TransactionId:,-1
UrlKey(Operation,CallerService,Url):(-1),(-1),https://webpoolsg20f03.infra.lync.com:443/CertProv/CertProvisioningService.svc
Secondary Key:
Tok
0222132535|AuthS|0|00|Reqponse(-1)AuthSvc,(102)AuthServiceUCMsgKey,(-1)pps,(14),(Expiry,TransactionId,Time,Type):(-1,-1,1487741135,1)IndicationCode:(200)Got User Certificate
0222132535|app1 |2|00|MsgAppRegistrationInternalState: Received, State 3
0222132535|sip |1|00|SipGotNewUserCert: pstNewUserCert[1131886644]
0222132535|sip |3|00|TLS-DSK:soWebTicketCbFunc: the event type is 9
0222132535|sip |4|00|TLS-DSK:soWebTicketCbFunc: Unhandled event received from webRTicket [9]
0222132535|sip |0|00|<<< Data received TLS
0222132535|sip |0|00| SIP/2.0 401 Unauthorized
0222132535|sip |0|00| ms-user-logon-data: RemoteUser
0222132535|sip |0|00| Date: Wed, 22 Feb 2017 05:27:25 GMT
0222132535|sip |0|00| WWW-Authenticate: TLS-DSK opaque="E30C2F6B", gssapi-data="FgMBEpUCAABNAwFYrSE904RvQRJWMPI6iQMjy3nY+3aknmx+wJ+dJy2LqCAINQAA0RKZigYWhn8LQ9HKBSR44CbenbXV2RE7NH5pbwA1AAAF/wEAAQALABIyABIvAAZwMIIGbDCCBFSgAwIBAgITWgAAx/PyNCBy00od+AABAADH8zANBgkqhkiG9w0BAQsFADCBizELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEVMBMGA1UECxMMTWljcm9zb2Z0IElUMR4wHAYDVQQDExVNaWNyb3NvZnQgSVQgU1NMIFNIQTIwHhcNMTUwMzEzMjM0MzE3WhcNMTcwMzEyMjM0MzE3WjAcMRowGAYDVQQDDBEqLm9ubG
0222132535|sip |0|00|
0222132535|sip |0|00| REGISTER sip:ucprimer.com;transport=tls SIP/2.0
0222132535|sip |0|00| Via: SIP/2.0/TLS 10.222.202.232:60618;branch=z9hG4bK323718ed169BD992
0222132535|sip |0|00| From: "vvx" <sip:[email protected]>;tag=B9A92F89-6F6343CE;epid=0004f2ae4b0d
0222132535|sip |0|00| To: <sip:[email protected]>
0222132535|sip |0|00| CSeq: 2 REGISTER
0222132535|sip |0|00| Call-ID: 7fae79d87a29829ae54a8b3071ae4b0d
0222132535|sip |0|00| Contact: <sip:[email protected]:60618;transport=tls>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:43a160e1-13ce-5cc6-804c-4a288a2c1873>"
0222132535|sip |0|00| User-Agent: Polycom/5.5.1.11526 PolycomVVX-VVX_600-UA/5.5.1.11526
0222132535|sip |0|00| Accept-Language: en
0222132535|sip |0|00| Ms-device-info: MAC=00-04-F2-AE-4B-0D, vendor=POLYCOM, version=PolycomVVX-VVX_600-5.5.1.11526
0222132535|sip |0|00| ms-keep-alive: UAC;hop-hop=yes
0222132535|sip |0|00| Supported: msrtc-event-categories,adhoclist,ms-cluster-failover,ms-userservices-state-notification,gruu-10,gruu
0222132535|sip |0|00| Event: registration
0222132535|sip |0|00| ms-subnet: 10.222.202.0
0222132535|sip |0|00| Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", targetname="SG20F03FES06.infra.lync.com", gssapi-data="FgMBAEQBAABAAwGS0Pl0EBC6TOz0gpjhtvXFtSAqobE5DDpeNvhd6Ls3MQAADgA5ADUAMwAvABYACgD/AQAACQAjAAAADwABAQ==", version=4
0222132535|sip |0|00| Max-Forwards: 70
0222132535|sip |0|00| Content-Length: 0
0222132535|sip |0|00|
0222132535|sip |0|00|>>> End of data send
0222132535|sip |1|00|CTcpSocket::SendData TLS queuedTxData = 0 TotalLen 1180 loop count 1 maxQueueDepth 40000
0222132535|sip |1|00|CTcpSocket::SendData TLS Sent 1180 loop count 1
0222132535|AuthS|0|00|Policy Dest:(201)AuthServicePolicyServiceKey:(102)AuthServiceUCMsgKey:(205)AuthSvcAOServiceRequestKey
Caller Service(-1):IndicationCode(0)
,TransactionID(-1)Data:SD:Key Data(User Key/Operation Key/Url Key):Uri:[email protected]
User/Domain:[email protected],
Url:
Operation:(102)AuthServiceUCMsgKey,Caller Service:(-1)Url,TransactionId:,-1
UrlKey(Operation,CallerService,Url):(-1),(-1),https://webpoolsg20f03.infra.lync.com:443/CertProv/CertProvisioningService.svc
Secondary Key:
Token Key/Data:TokenKey
0222132535|AuthS|0|00|Policy Dest:(201)AuthServicePolicyServiceKey:(102)AuthServiceUCMsgKey:(206)AuthSvcAOServiceReplyKey
Caller Service(-1):IndicationCode(200)Got User Certificate
,TransactionID(-1)Data:SD:Key Data(User Key/Operation Key/Url Key):Uri:[email protected]
User/Domain:[email protected],
Url:
Operation:(102)AuthServiceUCMsgKey,Caller Service:(-1)Url,TransactionId:,-1
UrlKey(Operation,CallerService,Url):(-1),(-1),https://webpoolsg20f03.infra.lync.com:443/CertProv/CertProvisioningService.svc
Secondary Key:
Tok
0222132535|AuthS|0|00|Reqponse(-1)AuthSvc,(102)AuthServiceUCMsgKey,(-1)pps,(14),(Expiry,TransactionId,Time,Type):(-1,-1,1487741135,1)IndicationCode:(200)Got User Certificate
0222132535|app1 |2|00|MsgAppRegistrationInternalState: Received, State 3
0222132535|sip |1|00|SipGotNewUserCert: pstNewUserCert[1131886644]
0222132535|sip |3|00|TLS-DSK:soWebTicketCbFunc: the event type is 9
0222132535|sip |4|00|TLS-DSK:soWebTicketCbFunc: Unhandled event received from webRTicket [9]
0222132535|sip |0|00|<<< Data received TLS
0222132535|sip |0|00| SIP/2.0 401 Unauthorized
0222132535|sip |0|00| ms-user-logon-data: RemoteUser
0222132535|sip |0|00| Date: Wed, 22 Feb 2017 05:27:25 GMT
0222132535|sip |0|00| WWW-Authenticate: TLS-DSK opaque="E30C2F6B", gssapi-data="FgMBEpUCAABNAwFYrSE904RvQRJWMPI6iQMjy3nY+3aknmx+wJ+dJy2LqCAINQAA0RKZigYWhn8LQ9HKBSR44CbenbXV2RE7NH5pbwA1AAAF/wEAAQALABIyABIvAAZwMIIGbDCCBFSgAwIBAgITWgAAx/PyNCBy00od+AABAADH8zANBgkqhkiG9w0BAQsFADCBizELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEVMBMGA1UECxMMTWljcm9zb2Z0IElUMR4wHAYDVQQDExVNaWNyb3NvZnQgSVQgU1NMIFNIQTIwHhcNMTUwMzEzMjM0MzE3WhcNMTcwMzEyMjM0MzE3WjAcMRowGAYDVQQDDBEqLm9ubG
0222132535|sip |0|00|
Web Sign-in Authentication Flow Summary
Its worth to note that the Web Sign-in process flow on a VVX is different from a typical modern authentication flow from a SfB client as the phone will not receive tokens directly from the ADFS server. Based on wireshark traces on the VVX during web sign-in, the high level authentication flow can be summarized in the following diagram:
1. User initiates Web Sign-in on the phone
2. Phone registers with Device Paring Service https://bootstrap.pinauth.services.skypeforbusiness.com:443 and gets a device pairing code
3. User login on the browser using the SIP Address
4. User gets redirected by Azure AD oAuth Service to our on-premise ADFS Proxy and is prompted to enter credentials
5. After credentials are validated ADFS provides the claims token to Azure AD STS
6. After entering the pairing code to Azure AD, Azure AD STS returns Refresh and Access tokens to the phone
7. Phone uses access token to authenticate with Skype for Business Online
Its worth to note that the Web Sign-in process flow on a VVX is different from a typical modern authentication flow from a SfB client as the phone will not receive tokens directly from the ADFS server. Based on wireshark traces on the VVX during web sign-in, the high level authentication flow can be summarized in the following diagram:
1. User initiates Web Sign-in on the phone
2. Phone registers with Device Paring Service https://bootstrap.pinauth.services.skypeforbusiness.com:443 and gets a device pairing code
3. User login on the browser using the SIP Address
4. User gets redirected by Azure AD oAuth Service to our on-premise ADFS Proxy and is prompted to enter credentials
5. After credentials are validated ADFS provides the claims token to Azure AD STS
6. After entering the pairing code to Azure AD, Azure AD STS returns Refresh and Access tokens to the phone
7. Phone uses access token to authenticate with Skype for Business Online
Conclusion
Its also important to note that Web Sign-in for the VVX is not supported for on-premise Skype for Business deployments at this time. Only Skype for Business Online accounts can be used. For more information, see https://support.office.com/en-ie/article/Deploying-Skype-for-Business-Online-phones-faa17eb3-7483-4984-87f2-815d981b68ae
To learn more about Modern Authentication, please visit the following websites:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios
https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/
https://docs.microsoft.com/en-sg/azure/active-directory/develop/active-directory-protocols-oauth-code
Its also important to note that Web Sign-in for the VVX is not supported for on-premise Skype for Business deployments at this time. Only Skype for Business Online accounts can be used. For more information, see https://support.office.com/en-ie/article/Deploying-Skype-for-Business-Online-phones-faa17eb3-7483-4984-87f2-815d981b68ae
To learn more about Modern Authentication, please visit the following websites:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios
https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/
https://docs.microsoft.com/en-sg/azure/active-directory/develop/active-directory-protocols-oauth-code
RSS Feed