C76676: Extra linebreaks in link table breaking content in en-us (#11643)

* C76676: Extra linebreaks in link table breaking content in en-us

Localization team has reported source content issue that causes localized version to have broken/different format compared to en-us version.

* Update securing-wcf-data-services.md

Author: v-makoud

docs/framework/data/wcf/securing-wcf-data-services.md

@@ -23,13 +23,10 @@ WCF Data Services does not implement any kind of authentication of its own, but
 |Authentication Options|Description|  
 |----------------------------|-----------------|  
 |Anonymous authentication|When HTTP anonymous authentication is enabled, any principle is able to connect to the data service. Credentials are not required for anonymous access. Use this option only when you want to allow anyone to access the data service.|  
-|Basic and digest authentication|Credentials consisting of a user name and password are required for authentication. Supports authentication of non-Windows clients. **Security Note:**  Basic authentication credentials (user name and password) are sent in the clear and can be intercepted. Digest authentication sends a hash based-on the supplied credentials, which makes it more secure than basic authentication. Both are susceptible to man-in-the-middle attacks. When using these authentication methods, you should consider encrypting communication between client and the data service by using the Secure Sockets Layer (SSL). <br /><br /> Microsoft Internet Information Services (IIS) provides an implementation of both basic and digest authentication for HTTP requests in an ASP.NET application. This Windows Authentication Provider implementation enables a .NET Framework client application to supply credentials in the HTTP header of the request to the data service to seamlessly negotiate authentication of a Windows user. For more information, see [Digest Authentication Technical Reference](https://go.microsoft.com/fwlink/?LinkId=200408).<br /><br /> When you want to have your data service use basic authentication based on some custom authentication service and not Windows credentials, you must implement a custom ADP.NET HTTP Module for authentication.<br /><br /> For an example of how to use a custom basic authentication scheme with WCF Data Services, see the blog post [
-OData and Authentication – Part 6 – Custom Basic Authentication](https://devblogs.microsoft.com/odata/odata-and-authentication-part-6-custom-basic-authentication/)].|  
+|Basic and digest authentication|Credentials consisting of a user name and password are required for authentication. Supports authentication of non-Windows clients. **Security Note:**  Basic authentication credentials (user name and password) are sent in the clear and can be intercepted. Digest authentication sends a hash based-on the supplied credentials, which makes it more secure than basic authentication. Both are susceptible to man-in-the-middle attacks. When using these authentication methods, you should consider encrypting communication between client and the data service by using the Secure Sockets Layer (SSL). <br /><br /> Microsoft Internet Information Services (IIS) provides an implementation of both basic and digest authentication for HTTP requests in an ASP.NET application. This Windows Authentication Provider implementation enables a .NET Framework client application to supply credentials in the HTTP header of the request to the data service to seamlessly negotiate authentication of a Windows user. For more information, see [Digest Authentication Technical Reference](https://go.microsoft.com/fwlink/?LinkId=200408).<br /><br /> When you want to have your data service use basic authentication based on some custom authentication service and not Windows credentials, you must implement a custom ADP.NET HTTP Module for authentication.<br /><br /> For an example of how to use a custom basic authentication scheme with WCF Data Services, see the blog post [OData and Authentication – Part 6 – Custom Basic Authentication](https://devblogs.microsoft.com/odata/odata-and-authentication-part-6-custom-basic-authentication/).|  
 |Windows authentication|Windows-based credentials are exchanged by using NTLM or Kerberos. This mechanism is more secure than basic or digest authentication, but it requires that the client be a Windows-based application. IIS also provides an implementation of Windows authentication for HTTP requests in an ASP.NET application. For more information, see [ASP.NET Forms Authentication Overview](https://docs.microsoft.com/previous-versions/aspnet/7t6b43z4(v=vs.100)).<br /><br /> For an example of how to use Windows authentication with WCF Data Services, see the blog post [OData and Authentication – Part 2 – Windows Authentication](https://devblogs.microsoft.com/odata/odata-and-authentication-part-2-windows-authentication/).|  
-|ASP.NET forms authentication|Forms authentication lets you authenticate users by using your own code and then maintain an authentication token in a cookie or in the page URL. You authenticate the user name and password of your users using a login form that you create. Unauthenticated requests are redirected to a login page, where the user provides credentials and submits the form. If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests. For more information, see [Forms Authentication Provider](https://docs.microsoft.com/previous-versions/aspnet/9wff0kyh(v=vs.100)). **Security Note:**  By default, the cookie that contains the forms authentication ticket is not secured when you use forms authentication in a ASP.NET Web application. You should consider requiring SSL to protect both the authentication ticket and the initial login credentials. <br /><br /> For an example of how to use forms authentication with WCF Data Services, see the blog post [
-OData and Authentication – Part 7 – Forms Authentication](https://devblogs.microsoft.com/odata/odata-and-authentication-part-7-forms-authentication/).|  
-|Claims-based authentication|In claims-based authentication, the data service relies on a trusted "third-party" identity provider service to authenticate the user. The identity provider positively authenticates the user that is requesting access to data service resources and issues a token that grants access to the requested resources. This token is then presented to the data service, which then grants access to the user based on the trust relationship with the identity service that issued the access token.<br /><br /> The benefit of using a claims-based authentication provider is that they can be used to authenticate various types of clients across trust domains. By employing such a third-party provider, a data service can offload the requirements of maintaining and authenticating users. OAuth 2.0 is a claims-based authentication protocol that is supported by Windows Azure AppFabric Access Control for federated authorization as a service. This protocol supports REST-based services. For an example of how to use OAuth 2.0 with WCF Data Services, see the blog post [
-OData and Authentication – Part 8 – OAuth WRAP](https://devblogs.microsoft.com/odata/odata-and-authentication-part-8-oauth-wrap/).|  
+|ASP.NET forms authentication|Forms authentication lets you authenticate users by using your own code and then maintain an authentication token in a cookie or in the page URL. You authenticate the user name and password of your users using a login form that you create. Unauthenticated requests are redirected to a login page, where the user provides credentials and submits the form. If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests. For more information, see [Forms Authentication Provider](https://docs.microsoft.com/previous-versions/aspnet/9wff0kyh(v=vs.100)). **Security Note:**  By default, the cookie that contains the forms authentication ticket is not secured when you use forms authentication in a ASP.NET Web application. You should consider requiring SSL to protect both the authentication ticket and the initial login credentials. <br /><br /> For an example of how to use forms authentication with WCF Data Services, see the blog post [OData and Authentication – Part 7 – Forms Authentication](https://devblogs.microsoft.com/odata/odata-and-authentication-part-7-forms-authentication/).|  
+|Claims-based authentication|In claims-based authentication, the data service relies on a trusted "third-party" identity provider service to authenticate the user. The identity provider positively authenticates the user that is requesting access to data service resources and issues a token that grants access to the requested resources. This token is then presented to the data service, which then grants access to the user based on the trust relationship with the identity service that issued the access token.<br /><br /> The benefit of using a claims-based authentication provider is that they can be used to authenticate various types of clients across trust domains. By employing such a third-party provider, a data service can offload the requirements of maintaining and authenticating users. OAuth 2.0 is a claims-based authentication protocol that is supported by Windows Azure AppFabric Access Control for federated authorization as a service. This protocol supports REST-based services. For an example of how to use OAuth 2.0 with WCF Data Services, see the blog post [OData and Authentication – Part 8 – OAuth WRAP](https://devblogs.microsoft.com/odata/odata-and-authentication-part-8-oauth-wrap/).|  
 
 <a name="clientAuthentication"></a>   
 ### Authentication in the Client Library