Для одного я бы только вернул TokenID - некоторый уникальный идентификатор, чтобы четко идентифицировать пользователя и его подписку, о которой идет речь - из вашего первого звонка "аутентификации". Не нужно все время отправлять туда-сюда весь набор информации - эти данные нужны только службе на стороне сервера, поэтому вы можете оставить эту информацию на сервере и обращаться к ней только в коде своего сервера, когда это необходимо.
Так что этот первый вызов - вызов аутентификации - скорее всего, проверяет учетные данные, отправляемые по таблице базы данных, по таблице подписки, а затем помещает эту информацию (кто звонит, на основании какой подписки) и, возможно, какой-то дата / время истечения срока действия в таблицу «Действительных абонентов» и сгенерированный из нее идентификатор (GUID или что-то). Возможно, вы захотите ограничить «срок службы» TokenID - например, он действителен в течение 30 минут или около того - поэтому он не может быть взломан и постоянно использоваться после первого успешного вызова. Этот сгенерированный GUID затем возвращается как TokenID из вызова аутентификации и может использоваться в качестве идентификатора в каждом последующем вызове.
Такие вещи, как то, какой сервер баз данных использовать, на самом деле не имеют места в сообщениях, идущих туда и обратно - они строго важны для кода обслуживания на стороне сервера - просто оставьте это там!
Это определенно предпочтительная практика - помещать такую «метаинформацию», которая не является реальной информацией о ваших звонках, в заголовки и искать ее там. WCF поддерживает это довольно легко и просто - либо с помощью инспекторов сообщений ( образец для этого здесь и здесь ) на стороне клиента и службы, либо с помощью OperationContextScope (пример * сообщение в блоге ) здесь и здесь ) - оба прекрасно работают.