OSCAR login

Login stage I:   Authorization  Login stage II:   Protocol negotiation  Login stage III:   Services setup  Login stage IV:   Final actions  Example #1:   Login with MD5 based authorization  Example #2:   Login with channel 0x01 based authorization

Login stage I: Authorization         Currently there is two ways to pass authentification in OSCAR protocol. First is FLAP channel 0x01 authorization (password not crypted but roasted), second is MD5 based where password is MD5 crypted. In both ways server could return error or authorization cookie + BOS address. Here is both auth sequences (client<->server):  1. Channel 0x01 authorization (success)   <>   connect   Client connects to authorizer server   >>   cli_ident   Client send login request   <<   srv_cookie   Server reply via BOS address / cookie   <>   disconnect   Client disconnects from authorizer  2. MD5 based authorization   <>   connect   Client connects to authorizer server   >>   SNAC(17,06)   Client sends md5-authkey request   <<   SNAC(17,07)   Server sends md5-authkey string   >>   SNAC(17,02)   Client sends authorization request   <<   SNAC(17,03)   Server sends authorization reply   <>   disconnect   Client disconnects from authorizer      In channel 0x01 authorization server may replace srv_cookie packet reply via auth_failed packet which contain authorization error code. In MD5 based authorization sequence server always reply via SNAC(17,03) which may contain cookie / BOS address or authorization error code.      When authorization sequence successfully finishes client has authorization cookie, ip address and port of the BOS server. At this point it should disconnect from authorizer and connect to BOS. This is the point where login stage II (protocol negotiation) started.

Login stage II: Protocol negotiation         After authorization client should extract BOS server/auth cookie from reply packet, connect to BOS and send cookie via special FLAP channel 0x01 packet named cli_cookie. In reply server will return list of supported services - SNAC(01,03). Then client should ask needed services version numbers using SNAC(01,17). After that client will receive services version numbers server has - SNAC(01,18). Note that client never shouldn't send snacs to services not listed in SNAC(01,03). It should use service request SNAC(01,04) instead.  Protocol negotiation   <>   connect   Client connects to BOS server   >>   cli_cookie   Client sends cookie   <<   SNAC(01,03)   Server sends supported services list   >>   SNAC(01,17)   Client ask for services version numbers   <<   SNAC(01,18)   Server sends its services version numbers      After negotiation client should setup current connection. It request rate limitations information via SNAC(01,06). Then server will return connection rate limitations info - SNAC(01,07). At this point client start calculating its rate level on every SNAC it send. Server rate limitations information SNAC should be acked using SNAC(01,08). Now connection ready.  Protocol negotiation   >>   SNAC(01,06)   Client ask server for rate limits info   <<   SNAC(01,07)   Server sends rate limits information   >>   SNAC(01,08)   Client ack connection rate limits

Login stage III: Services setup         Most of the services has limitations which you can request via SNAC(xx,02). For example client should know max_contact_buddies for BLM service. ICBM service has message default limits and client can change them as you need. Client also should send its capabilities list to Location service.  Protocol negotiation   >>   SNAC(02,02)   Client ask server location service limitations   <<   SNAC(02,03)   Server replies via location service limitations   >>   SNAC(02,04)   Client sends its capabilities / profile to server   >>   SNAC(03,02)   Client ask server BLM service limitations   <<   SNAC(03,03)   Server replies via BLM service limitations   >>   SNAC(04,04)   Client ask server for ICBM service parameters   <<   SNAC(04,05)   Server sends ICBM service parameters to client   >>   SNAC(04,02)   Client change default ICBM parameters command   >>   SNAC(09,02)   Client ask server PRM service limitations   <<   SNAC(09,03)   Server sends PRM service limitations to client   >>   SNAC(13,02)   Client ask server for SSI service limitations   <<   SNAC(13,03)   Server sends SSI service limitations to client   >>   SNAC(13,05)   Client check if its local SSI copy is up-to-date   <<   SNAC(13,0F)   Server tell client its local copy up-to-date   >>   SNAC(13,07)   Client activates server SSI data      Note that this order is not strict and client can send several requests and then wait for replies. But it should remember about rate limitations.

Login stage IV: Final actions         This is last login actions you should perform. ICQ client at this stage set its DC information and status on main connection via SNAC(01,1E). Login sequence finishes by client ready SNAC(01,02) which contain version/build numbers for protocol dlls.  Final actions   >>   SNAC(01,1E)   Client sends its DC info and status to server   >>   SNAC(01,02)   Client READY command      After SNAC(01,02) client command server start broadcast client presence to its buddies and client start receiving messages and presence notifications. ICQ client should also check for offline messages.

Main | Basic | Login | Snaclist | Sequences | Misc | Changes | Credits | Terms